| |
| 2.37, pro100master (ok), 18:52, 10/07/2011 [^] [^^] [^^^] [ответить]
| –5 +/– |
 > И кто им мешал PostgreSQL использовать??
Postgre еще более ущербен на primaryKey-value. Его вселенная - приложения.
| | |
| 2.63, Odity (?), 08:57, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
А вы представляете что это значит? Такие гиганты говорят что настоящая БД не годится. Это как раньше пользовались при шифровании ключом в 56 бит и считалось что это достаточно, но на перед видилось что будут новые машины и что и 256 бит скоро будет не хватать. Просто наперед начать переписывать с нуля то что есть сейчас...это офигенный прогресс!!!!MS со своим 2008 SQL только бы хотелось узнать как,потянут базы от таких гигантов или нет? Думают ли они о будущем и то что ЭТОГО уже мало?
| | |
|
| 1.3, gegMOPO4 (ok), 15:22, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +13 +/– |
 Сперва они упираются в тормознутость PHP и решают написать компилятор из PHP в C. Потом они упираются в MySQL и решают написать свою БД. Что дальше? Небольшой [свечной] микропроцессорный заводик? Собственная сеть спутников?
| | |
| |
| 2.7, pavlinux (ok), 15:36, 10/07/2011 [^] [^^] [^^^] [ответить]
| +8 +/– |
 А почему бы и нет. Например аппаратное ускорение работы базы.
Тогда любой запрос можно превратить в один ioctl(SQL_REG, IO_SELECT, *data_pointer);
с другой стороны ускорителя :) втыкать всяки носители, хоть USB-плешку.
Две USB дыкри и кнопка [ FAST BACKUP ] - аналог dd if USB1 of USB2
| | |
| |
| 3.13, gegMOPO4 (ok), 15:48, 10/07/2011 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Это было бы занимательно. Только, учитывая опыт компилятора, не для простых смертных это, будет требовать гелиевого охлаждения и отдельного энергоподвода от ближайшей электростанции.
| | |
|
| 2.36, pro100master (ok), 18:50, 10/07/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
ну а что тут такого? Любой проект, если он растет, сталкивается с проблемами (не только масштабирования, но и бизнес, и сетью, и управлением, и разработкой). Их путь повторяет опыт Гугла: слабые ФС - делаем свою, слабые серверы - делаем (заказываем) свои и т.д.
я наблюдал несколько небольших компаний, которые с самого начала пытались делать сверхоптимизированные проекты - проели кучу денег, на запуск и раскрутку тупо не хватило.
| | |
| |
| 3.67, rshadow (ok), 11:33, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Согласен полностью. Если им не хватает чего то пусть пишут. Нам главное учесть их опыт и пропускать мимо ушей все эти "нанотехнологии". А то уже гугль пол инета готов закопать, эти вот sql готовы закопать ...
| | |
|
|
| 1.4, gegMOPO4 (ok), 15:26, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Интересно, они думают, что если SQL записывать в нижнем регистре, это избавит от проблем масштабируемости?
| | |
| |
| 2.6, 1 (??), 15:34, 10/07/2011 [^] [^^] [^^^] [ответить]
| +9 +/– |
интересно, ты думаешь что написав пару язвительных комментариев о том, чего не понимаешь, ты сможешь казаться специалистом в данном вопросе?
| | |
| |
| 3.20, Щекн Итрч (ok), 16:26, 10/07/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
 >> написав пару язвительных комментариев о том, чего не понимаешь,
>> ты сможешь казаться специалистом в данном вопросе?
а вдруг наоборот?
| | |
|
| 2.32, Щекн Итрч (ok), 17:57, 10/07/2011 [^] [^^] [^^^] [ответить]
| +3 +/– |
>> Интересно, они думают, что если SQL записывать в нижнем регистре,
>> это избавит от проблем масштабируемости?
Усовершенствования это круто, но ОТХОДИТЬ ОТ СТАНДАРТОВ SQL-синтаксиса -- нехорошо в кубе.
Граждане не просто регистром балуются, а мостырят какую-то "феню".
| | |
| |
| 3.45, volax (?), 19:36, 10/07/2011 [^] [^^] [^^^] [ответить]
| +5 +/– |
Это их сайт, их язык, их программисты и их сообщество, нифиг им совместимость? ИМХО, главное, чтобы работало
| | |
| |
| 4.52, Щекн Итрч (ok), 21:57, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
"Их сайт", то есть Фейсбук, как раз нуждается в совместимости, ибо на MySQL.
А Stonebraker просто рядом стоит.
Соблазняя Фейсбуков отойти от ANSI синтаксиса.
| | |
| |
| |
| 6.72, Щекн Итрч (ok), 15:49, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
Ткните пальцем. Во многих.
И:
Вас ист дас "nosql"? "Key-value"?
Какое отношение "k-v" имеет к обсуждаемому тут NewSQL?
| | |
|
|
|
| 3.59, ананим (?), 07:29, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>Усовершенствования это круто, но ОТХОДИТЬ ОТ СТАНДАРТОВ SQL-синтаксиса -- нехорошо в кубе.
тем более не понятно, как изменение синтаксиса решит вопрос масштабирования и производительности.
Зыж
ну давайте все говорить по-английски.
Глядишь и ввп удвоится.
| | |
|
| 2.54, Щекн Итрч (ok), 22:06, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
Этот человек производит впечатление психа.
На сайте, кстати, ничего, кроме рассуждений о том, что "синтаксис SQL громоздок".
И цель проекта заявлена, собственно, как новый синтаксис и только новый синтаксис.
О движке и его производительности ни звука.
| | |
| 2.68, rshadow (ok), 11:36, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
Насколько я знаю SQL в mysql регистронезависим. Так что проблему производительности можно решить решить простой заменой. <сарказм>
| | |
|
| 1.9, metallic (ok), 15:38, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 А что, кому-то от этого плохо? Думаю сообщество только от этого выиграет, они же не будут исходники зажимать? Так и появляются хорошие открытые проекты, которые разрабатываются за деньги больших богатых контор.
| | |
| |
| 2.15, gegMOPO4 (ok), 15:50, 10/07/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это не плохо. Это просто выглядит несколько… забавно. Весёлая компания.
| | |
| 2.73, Щекн Итрч (ok), 15:55, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
> А что, кому-то от этого плохо? Думаю сообщество только от этого выиграет,
> они же не будут исходники зажимать? Так и появляются хорошие открытые
> проекты, которые разрабатываются за деньги больших богатых контор.
КТО и ЧТО "выиграет" от синтаксиса НАД SQL???
Вы на сайт NewSQL заходили?
| | |
|
| |
| 2.26, anonymous (??), 17:34, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Смахивает на рекламу NewSQL.
чем и является, собственно. «мы наш, мы новый мир построим! дайте бабла уже!»
| | |
|
| 1.12, Аноним (-), 15:48, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Гугль давно свой велосипед изобрел для таких целей. Фэйсбук тоже доэволюционировал до этого, видимо
| | |
| |
| 2.16, all_glory_to_the_hypnotoad (ok), 15:53, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
 У гугла немного другой круг задач, т.е. цели там другие. А так есть похожие открытые велосипеды как у гугла - apache hadoop. Ява, но конторы с аналогичными целями его успешно используют.
| | |
|
| |
| |
| 3.33, anonymus (?), 17:58, 10/07/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
В статье представлены 6 компаний, у которых есть масштабируемые СУБД.
| | |
| |
| 4.53, Щекн Итрч (ok), 21:59, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> В статье представлены 6 компаний, у которых есть масштабируемые СУБД.
-- ни одна из которых проблем, которые "6 компаний" берутся порешать, -- не решила.
| | |
|
|
| 2.78, VoDA (ok), 18:34, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > не понял, за счет чего повышается производительность?
за счет разнесения на разные сервера и развязывания обработки. поскольку нет требования консистентности, то не требуется координатор транзакций - а он бутылочное горлышко любой распределенной БД. Раз убрали боттел-нек, то и скорость серьезно повышается. Минус - переход от консистентности к "Eventual consistency"
Eventual consistency - это что при прекращении нагрузки система самостоятельно раскатит все транзакции по всем серверам и вся БД придет в согласованное состояние. Но поскольку нагрузка никогда не будет уменьшена, то и согласованность БД не будет достигнута ;)
| | |
|
| 1.19, Аноним (-), 16:09, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
Когда до людей дойдёт, что централизованные сервисы ненужны?
Всем известный пример - есть ICQ, которая стабильно падает и глючит, и есть джаббер, который работает. И есть распределённый email, который спокон веков работал на любом копеечном железе и как-то обходился без ВЫСОКИХ НАГРУЗОК, МАСШТАБИРОВАНИЯ и NOSQL. И для социальных сетей давно есть распределённая Diaspora, в которой каждый сам хозяин своих даных - но нет, мыши плакали, кололись, но упорно несли свои личные фконтактик и ффейсбук. А создатели вктонактика и фейсбука мужественно борются с проблемами масштабирования, которые сами же себе и придумали. Воистину, все беды от дурости.
| | |
| |
| 2.21, Аноним (-), 16:30, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> давно есть распределённая Diaspora
Официально ещё не вышла, но да - есть серверы со свободной регистрацией.
| | |
| |
| 3.22, Аноним (-), 16:43, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
Что значит "не вышла"? git clone git://github.com/diaspora/diaspora.git
| | |
| |
| 4.40, Аноним (-), 19:24, 10/07/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
THIS IS ALPHA SOFTWARE AND SHOULD BE TREATED ACCORDINGLY. IT IS FUN TO GET RUNNING, BUT EXPECT THINGS TO BE BROKEN.
| | |
| |
| 5.47, Аноним (-), 19:40, 10/07/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вконтактик всю жизнь ALPHA SOFTWARE, и разве кого-то это останавлиет?
| | |
|
|
| 3.23, Аноним (-), 16:45, 10/07/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Официально ещё не вышла, но да - есть серверы со свободной регистрацией.
Гугол+ тоже ещё официально не вышел, а все уже бегут в очередь становиться, лол.
| | |
|
| 2.35, Алексей Морозов (ok), 18:32, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Когда до людей дойдёт, что централизованные сервисы ненужны?
Тогда, когда некоторая [коммерческая] компания проведёт, по сути, рекламную акцию среди _некомпьютерного_ населения по внедрению распределённой социальной сети. Для этого должны быть созданы и отшлифованы пригодные для _некомпьютерного_ населения клиенты и _сервера_ , налажено взаимодействие с аналогичными службами (гейты в твиттер, фейсбук и blogger.com - популярная тема) и так далее и тому подобное.
А на выходе, напомню, - _распределённая_ социальная сеть. С такой сети и персональные данные фиг поколлекционируешь :) В общем, не слишком очевиден способ монетизации, ведь вводить абонентку или перегрузить рекламой - это подписать себе смертный приговор ещё на взлёте. Вот и не занимается этим никто всерьёз.
А "мыши" и прочие "хомячки", с одной стороны, не воспринимают свои персональные данные как нечто коммерчески ценное и приватное, а с другой - чаще всего не задумываются над тем, что хозяин ресурса обладает полным доступом к тому, что они показали хоть кому-то.
| | |
| 2.83, XoRe (ok), 02:01, 12/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > Когда до людей дойдёт, что централизованные сервисы ненужны?
Фейсбук приносит деньги акционерам фейсбука?
Значит, фейсбук нужен.
Как минимум, нужен этим самым акционерам.
Вложить бабло в разработку красивого сайта, прорекламировать, нагнать пользователей, поднять посещаемость, ввести платные услуги, получить ещё больше бабла на выходе.
Вот и вся любовь.
| | |
|
| 1.25, Аноним (-), 17:32, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> есть только один выход из сложившейся проблемы - сделать невозможное и переписать весь код. Эта проблема касается и многих других web-компаний
Вообще почему ограничились только Web-компаниями мне например не нравиться что ядро подтормаживает когда make QT в сто потоков ставишь ;)
| | |
| |
| |
| 3.70, Odity (?), 11:50, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> make QT
> у тебя есть исходники QuickTime? поделись!
^)))))))))))))))) блин. я долго так не плакал на работе...
| | |
|
|
| 1.28, Аноним (-), 17:38, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> который имеет значительно более высокую производительность, чем обычные SQL DB,
> при этом гарантирует выполнение требований ACID. NewSQL пока находится на
> стадии проектирования, ещё даже не принят язык запросов - решается вопрос о
> выборе между синтаксисом похожим на Java и синтаксисом, напоминающим
> обычные SQL-запросы.
Отлично... Еще не начали делать, а уже говорят что будет быстрее. Запросы лучше писать в виде функций и запросов примитивных. То есть в идеале уход от SQL и приход к чуть ли не ручному foreach. Только тогда программисты смогут сами понимать на сколько сложно искать что-то... И не потребуеться много времени на разор SQL.
| | |
| |
| 2.31, anonymous (??), 17:54, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Только тогда программисты смогут сами понимать на сколько сложно искать что-то...
ты не поверишь: компьютеры были придуманы как раз для того, чтобы поменьше тупой ручной работы делать. сюрпрайз?
| | |
| 2.38, all_glory_to_the_hypnotoad (ok), 18:57, 10/07/2011 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>То есть в идеале уход от SQL и приход к чуть ли не ручному foreach. Только тогда программисты смогут сами понимать на сколько сложно искать что-то... И не потребуеться много времени на разор SQL.
Большинство программистов не сможет написать "форичами" план выполнения быстрее чем это делают оптимизаторы запросов в нормальных СУБД. А php быдлокодеры были, есть и будут независимот ни от чего делать на каждый чих по 1000 запросов к БД.
> И не потребуеться много времени на разор SQL.
на разбор SQL выражений времени и так много не требуется.
| | |
| |
| 3.75, Fantomas (??), 16:05, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> А php быдлокодеры были, есть и будут независимот ни от чего делать на каждый чих по 1000 запросов к БД
SELECT current_date;
:-)))))))))))))))
| | |
|
|
| 1.34, getfr (?), 18:05, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Похоже, что проекту, указанному в новости, не хватает одного, но грамотного руководителя проекта.
При грамотном руководителе проекта мы бы знали, что проект работает, а не видели периодические отмазки, выполнзающие наружу.
IMHO, естественно.
| | |
| 1.39, pro100master (ok), 19:06, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
1) sql - гавно, перепишем
2) реляционный БД - гавно - перепишем
Ну да - такой подход veni, vidi, vici крут. Чего там - стандарт SQL придумали трусы. Почитать известнейших теоретиков БД тоже не судьба - читать тоже придумали трусы. Объектные БД уже были (и еще есть - ниша специфичная) и как-то популярности не набрали.
| | |
| 1.43, Аноним (-), 19:28, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
"NewSQL пока находится на стадии проектирования", но уже "имеет значительно более высокую производительность, чем обычные SQL DB"
у них бенчмарк через libastral работает?
| | |
| |
| |
| 3.50, lucentcode (ok), 20:43, 10/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
 А про то, что при разработке вначале пишут прототип на чём-то лёгком из ООП-языков, вы слышали? Если прототип показывает увеличение производительности, то релиз данной БД будет намного производительней прототипа.
| | |
| |
| 4.56, all_glory_to_the_hypnotoad (ok), 22:52, 10/07/2011 [^] [^^] [^^^] [ответить]
| +4 +/– | |
Не смешите, с такими ёмкими проектами так не бывает. И лёгкий язык даст слишком большую просадку по скорости какая бы там продвинутая архитектура не была. И существенно продвинутую архитектуру придумать практически невозможно, из статьи же что говорит сам автор о NoSQL:
"Кроме этого, по мнению Стоунбрейкера NoSQL обладает не сильно возросшей производительностью относительно традиционных SQL-ориентированных СУБД"
Т.е. ноэскюэльщики с наскока существенно решить ничего не смогли. И прототипы всегда имеют более облегчённый функционал, который потом становится ещё сложнее.
Подобные проекты пишутся только "на удачу", т.е. с надеждой что выбранная архитектура и дальнейшая многогодовая разработка действительно даст хороший результат. Не может у него быть такого прототипа сейчас.
| | |
|
|
|
| 1.49, lucentcode (ok), 20:40, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Правильно мыслит товарищ, надеюсь что синтаксис запросов выберут единственно верный: NewSQL, вариант 'Jdb'. Очень правильный синтаксис. А мерзкий недоязычок SQL надо закопать.
| | |
| |
| 2.51, Аноним (-), 21:52, 10/07/2011 [^] [^^] [^^^] [ответить] | +5 +/– | до превратить WHERE T ID T2 ID в t1 join t2 t1 id t2 id это круто, это п... большой текст свёрнут, показать | | |
| |
| 3.77, brother anon (?), 17:55, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
Такие портянки в приличных местах не показывают.
Одни только магические константы чего стоят.
| | |
| |
| 4.84, Аноним (-), 09:06, 12/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Такие портянки в приличных местах не показывают.
> Одни только магические константы чего стоят.
вы с этим к 1с сходите.
| | |
| |
| 5.86, brother anon (?), 14:20, 12/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> вы с этим к 1с сходите.
В 1с код пишется на языке 1с, а не на голом SQL-е, так что мимо кассы.
| | |
|
|
|
|
| 1.55, mf (?), 22:40, 10/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Баян, работающая версия которого называется LINQ(2db). Проблема выразительности языка, что в его работающем решении, что в примерах не решена.
| | |
| 1.64, ptr (??), 09:25, 11/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 На мой взгляд, бесполезное занятие себе господа выдумали. Да, у SQL есть проблемы. Много случаев, когда приходится заниматься копированием подзапросов или плодить пачки VIEW. Полный бардак с хинтами. Беда с объединением множеств (UNION тормоз, а FULL JOIN повесишься фильтровать). А здесь предлагается просто изменением синтаксиса SQL решать проблемы производительности. Не поддерживаю...
| | |
| |
| |
| 3.79, ptr (??), 21:46, 11/07/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> UNION ALL еще не изобрели?
Я же сказал - тормоз. Пусть есть у меня достаточно сложный запрос по двум десяткам таблиц с вложенными SELECT. Пусть мне надо выбрать из него два пересекающихся подмножества с разными GROUP BY. В итоге мне приходится или оформлять этот запрос как VIEW и объединять два запроса через UNION, либо просто копировать этот запрос для второй части. В любом случае, ни Postgres, ни MSSQL, ни Oracle, ни MySQL не понимают, что можно сделать одну выборку, а не две.
| | |
| |
| |
| 5.87, ptr (??), 08:06, 13/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Неправда. В Pg, Оракл и некоторых других СУБД есть оконные функции, часть
> подобных задач с их помощью решать можно.
Вот и подтверждение моему утверждению. Проблема известна, некоторые разработчики БД придумывают расширения для SQL, пытаясь решить проблему. Хотя более правильным, была бы разработка либо нового стандарта SQL(что хуже), либо нового языка запросов к БД.
| | |
|
| |
| 5.88, ptr (??), 08:08, 13/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> В любом случае, ни Postgres, ни MSSQL, ни Oracle, ни MySQL
>> не понимают, что можно сделать одну выборку, а не две.
> http://www.postgresql.org/docs/9.0/static/queries-with.html
Знаю. Но при построении отчета дополнительные условия WHERE я могу наложить только на последний SELECT. Из-за этого вложенные гребут все не фильтруя - прощай оптимизация.
| | |
|
|
|
|
| 1.80, Кодер (?), 21:57, 11/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Переписывать SQL в синтаксисе Джабы (ну или в другом регистре! :) ) - смысла нет, тут нужен принципиально другой подход. Мне вот, извините за кощунство, принцип FoxPro кажется чем-то перспективным. Т.е. мы не просто закинули на сервер монстр-запрос, а на низком уровне говорим серверу, что-откуда взять, как отфильтровать и куда приджойнить. Каков бы ни был оптимизатор, человек лучше знает СЕМАНТИКУ данных, т.е. его запросы будут априори лучше. Да и сам SQL довольно неуклюж для нетривиальных задач - он оперирует множествами, а это не всегда удобно.
| | |
| |
| 2.85, Щекн Итрч (ok), 10:02, 12/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
Мне тоже нравится подход, когда любой запрос (даже если движок имеет другой фронт) транслируется в SQL, который предоставляется мне для ревизии.
| | |
| 2.89, ptr (??), 08:11, 13/07/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Каков бы ни был оптимизатор,
> человек лучше знает СЕМАНТИКУ данных, т.е. его запросы будут априори лучше.
Увы, это часто совсем не так. Человек не знает, да и не может знать, статистик таблиц БД.
> Да и сам SQL довольно неуклюж для нетривиальных задач - он
> оперирует множествами, а это не всегда удобно. | | |
|
| 1.91, Аноним (-), 15:47, 19/12/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Автор этой статьи АБСОЛЮТНО не понимает о чем пишет. И ни один(!) комментатор не понял этого.
Этот тупица взял отличную статью от GigaOM и приписал туда несуществуюший _проект_ NewSQL. Несуществующий проект затем был привязан к _проекту синтаксиса_ мертвого с 2003го (!) года на sourceforge.
VoltDB кстати работает отлично.
| | |
|
