Анонсирован (http://highscalability.com/blog/2013/11/25/how-to-make-an-in... первый альфа-выпуск новой открытой реляционной СУБД InfiniSQL (http://www.infinisql.org/), нацеленной на достижение показателей производительности и масштабируемости NoSQL-систем при предоставлении классического SQL-интерфейса для доступа к данным. InfiniSQL развивается одним из бывших инженеров компании Visa как полностью свободный проект, без разделения на community и enterprise версии. Код InfiniSQL (https://github.com/infinisql/infinisql) распространяется под лицензией AGPLv3, а библиотеки для создания хранимых процедур под лицензией LGPLv3.СУБД состоит из двух частей - демона на языке Си++, использующего модель акторов (http://ru.wikipedia.org/wiki/%D0%9C%D0%B... для распараллеливания операций без блокировок, и менеджера ресурсов, написанного на языке Python. Клиентский интерфейс совместим с PostgreSQL, т.е. вместе с InfiniSQL могут использоваться приложения, собранные с использованием клиентских библиотек PostgreSQL и таких модулей, как DBD::Pg.
Построенный с использованием InfiniSQL тестовый кластер, состоящий из 12 узлов на базе типовых серверов (четырёхядерные CPU Intel Xeon E31230 3.30GHz, 8GB ОЗУ, 1TB SATA НЖМД, 2 x Intel 82579LM Gigabit Ethernet), смог обеспечить (http://www.infinisql.org/blog/2013/1112/benchmarking-infinisql) производительность на уровне 528 тысяч (в пике 542 тыс.) сложных транзакций в секунду при обработке более 100 тысяч одновременных соединений. Тестирование было проведено с использованием утилиты pgbench (http://www.postgresql.org/docs/9.2/static/pgbench.html). Все проведённые тесты документированы (http://www.infinisql.org/blog/2013/1112/benchmarking-infinisql) и легко воспроизводимы. На текущем этапе развития СУБД ещё не готова для промышленного использования, но уже может быть задействована для экспериментов и начального внедрения.
InfiniSQL поддерживает подмножество стандарта SQL-92, в том числе Ad hoc-запросы (http://ru.wikipedia.org/wiki/Ad_hoc#.D0.97.D0.B0.D0.BF.D1.80... и хранимые процедуры. СУБД обеспечивает три первых требования ACID к выполнению транзакций (атомарность, согласованность, изолированность). Отсутствие поддержки четвёртого требования, долговечности, является ценой высокой производительности СУБД. Дело в том, что InfiniSQL хранит данные только в оперативной памяти, на данном этапе разработки пока не предоставляя средств для обеспечения надёжного сохранения информации в случае сбоя всего кластера. В случае проблем, охватывающих все узлы остаётся полагаться на средства резервного копирования. В будущем данная проблема будет устранена, и СУБД InfiniSQL будет доведена до полного соответствия требованиям ACID.Хранимые в таблицах данные и индексы распределены по всем узлам кластера, при необходимости увеличения размера хранилища достаточно добавить новые узлы (горизонтальная масштабируемость). Клиент может подключиться к любому узлу и получить доступ к данным кластера в целом, который выглядит как одна неразрывная БД. Архитектура (http://www.infinisql.org/docs/overview/) InfiniSQL предусматривает наличие двух процессов: менеджера и демона хранения. Демон хранения занимается приёмом соединений от клиентов, выполнением запросов и хранением данных. Кроме доступа к локально хранимым данным, в процессе выполнения запроса демон также обращается и к данным других демонов.
Менеджер отвечает за запуск демонов хранения, их настройку, мониторинг работоспособности и управление топологией кластера. При необходимости менеджер запускает новые экземпляры демонов хранения и обеспечивает распределение данных в кластере, в том числе выполняет перестроение кластера в случае изменения топологии (например, вы выводе или добавлении узла) и следит за выполнением требований отказоусточивости за счёт дублирования данных на разных узлах. В настоящее время возможности менеджера сильно ограничены и сводятся к запуску демонов, остальные возможности планируется реализовать в будущем.URL: http://highscalability.com/blog/2013/11/25/how-to-make-an-in...
Новость: http://www.opennet.me/opennews/art.shtml?num=38553
> Код InfiniSQL распространяется под лицензией AGPLv3,не взлетит.
Обрисуйте ход ваших мыслей, сударь.
> Обрисуйте ход ваших мыслей, сударь.Код ему зажать не дают, видите ли. Хотя оно если и взлетит то как-то сильно местами, ибо такие штуки - просто нишевая фиговина, нужная десяткам-сотням инсталляций на всю планету.
Да ладно - "сотня-на-планету" это в нынешнем состоянии, после допиливания acid и кластерного менеджера будет идеальная замена постгресу, да ещё и с правильной лицензией!
После запиливания D из acid - оно будет не быстрее постргесса. dixi
Вы все перепутали, это у постгрес правильная лицензия, в отличие от этого поделия.
> Вы все перепутали, это у постгрес правильная лицензия, в отличие от этого поделия.У Oracle RDBMS - еще правильнее!
> да ещё и с правильной лицензией!Проприетарщики смотрят на вас с осуждением.
> Обрисуйте ход ваших мыслей, сударь.Как говорил линуксмастрип, еще ни один проект под открытой лицензией не взлетел.
All hail RDBMS!
Вот пусть и находится в этом радужном неведении.
Всё хорошо, всё розовое.
Affero - это не открытая, это ректальный зонд для корпораций. А корпорации, в отличие от юзеров, очень плохо относятся к ректальным зондам.
> Affero - это не открытая, это ректальный зонд для корпораций. А корпорации,
> в отличие от юзеров, очень плохо относятся к ректальным зондам.То-то, я смотрю, корпорации совсем на линукс забили.
>Affero - это не открытая, это ректальный зонд для корпораций.Типа гугл, фейсбук, жж,..., яндекс,..?
Или для тех, кого вышеперечисленные обува... обслуживают?
>Обрисуйте ход ваших мыслей, сударь.Миссия импосибл.
Они вон до сих пор окуевают почему этот недо-сиквел, мускуль, не только получил распространение, но ещё и дохнуть не собирается. А ведь его душили-душили, душили-душили, …
> Обрисуйте ход ваших мыслей, сударь.Для этого потребуется сперва Back2SQL... [бэктускуль]
Да найти желающих поддержать из тех кому она может пригодиться в пром. применении будет сложновато.
Да и так что то не особо понятно нужно ли оно.
Т.к. горизонтальная расширяемость, насколько я понял, тут немного условная, ( на каждую следующую еденицу хранимой информации нужны всё большие аппаратные ресурсы ).
> ... без разделения на community и enterprise версии ...Может и не взлететь, кормится-то они с чего собираются, да и на развитие "денешка" нужна.
> Дело в том, что InfiniSQL хранит данные только в оперативной памяти.Не удивительно тогда, что оно так шустро работает.
Готовятся к приходу mram - всё правильно, ящитаю.
>> Дело в том, что InfiniSQL хранит данные только в оперативной памяти.
> Не удивительно тогда, что оно так шустро работает.Поправьте меня, но 1 Тб в оперативку целиком не запихнешь. Это раз. И два - у Оракла уже есть такое решение.
> Поправьте меня, но 1 Тб в оперативку целиком не запихнешь. Это раз.А кто обязывает использовать это решение для таких тяжелых баз?
> И два - у Оракла уже есть такое решение.
То-то, я смотрю, младший менеджер оракла распереживался, кудахчет горестно :D
впихнёшь в память сколько хочешь. Бери много машин и делай из них кластер. Сейчас на машине уже может быть порядка 128 Гб, кластер из 8-10 машин легко будет хранить 1 Тб
Чо значит может быть?! Это стандартно на всех новых блейдах от голубых и принтерщиков.
На вполне обычном чипсете C602 от Intel - до 768GB
> Не удивительно тогда, что оно так шустро работает.но
> ... на данном этапе разработки пока не предоставляя средств для обеспечения надёжного сохранения информации в случае сбоя всего кластера.
Интересно кому нужно такое щасте ?
Durability в ACID обычно переводят как "надежность", а не "долговечность". Поправьте, плиз, глаза режет.
>нацеленной на достижение показателей производительности и масштабируемости NoSQL-систем
>масштабируемости NoSQL-системВот с этого момента, поподробнее плиз (в оригинале об этом ни слова).
ИМХО, главная трабла (при использовании в веб'е) PostgreSQL не в быстродействии, а чрезмерно сложном механизмах горизонтального масштабирования. Если сравнить с той же MongoDB - так небо и земля, по ходу.
А из этого вопрос: я правильно понимаю, что в этой новой БД "ис каропки" горизонтальное масштабирование? И что я могу добавить нод в, - пользуясь терминологией MongoDB, - сегмент, не заморачиваясь вопросами типа: "А какой у меня алгоритм распределения данных по сегментам?" и "Как мне перераспределить данные после добавления нового нода?"
Если это так, и если есть совместимость с PostgreSQL, то это... очень интересно.
>>нацеленной на достижение показателей производительности и масштабируемости NoSQL-систем
>>масштабируемости NoSQL-систем
> Вот с этого момента, поподробнее плиз (в оригинале об этом ни слова).
> ИМХО, главная трабла (при использовании в веб'е) PostgreSQL не в быстродействии,
> а чрезмерно сложном механизмах горизонтального масштабирования. Если сравнить с той же
> MongoDB - так небо и земля, по ходу.Такого решения нет ни у кого. RAC мы не считаем.
> А из этого вопрос: я правильно понимаю, что в этой новой БД
> "ис каропки" горизонтальное масштабирование? И что я могу добавить нод в,Неправильно. Когерентность кэшей не решена никем.
> - пользуясь терминологией MongoDB, - сегмент, не заморачиваясь вопросами типа: "А
> какой у меня алгоритм распределения данных по сегментам?" и "Как мне
> перераспределить данные после добавления нового нода?"Без этого о масштабировании по горизонтали можно забыть.
> Если это так, и если есть совместимость с PostgreSQL, то это... очень
> интересно.Нет. Не интересно. PSQL отнюдь не лидер на рынке RDBMS/
> PSQL отнюдь не лидер на рынке RDBMSНе лидер по какому набору критериев?
> PSQL отнюдь не лидер на рынке RDBMS/смотря среги каокго сегмента. Если брать открытые рСУБД, то PG вообще единственная такая.
> Такого решения нет ни у кого. RAC мы не считаем.RAC тоже горизонтально не масштабируется.
если нужно горизонтальное масштабирование в pgsql используйте plproxy от skype.
Это, отнюдь, не одно и тоже. В смысле, возможности mongo и plproxy. Первая полностью прозрачна для приложения (приложение даже и не знает о его существовании), для работы со вторым - требуется использовать свой язык запросов, что на практике выливается в допиливание ОРМа. По мне так проще ОРМ сменить на сделанный под монго, чем допиливать и далее самостоятельно поддерживать ОРМ под постгри.
> Отсутствие поддержки четвёртого требования, надежности, является ценой высокой производительности СУБД. Дело в том, что InfiniSQL хранит данные только в оперативной памяти, пока не предоставляя средств для обеспечения надёжного сохранения информации в случае сбоя всего кластеранахер не нужно, четвёртое требованаие обычно нужнее всех остальных, тем более для реляционной СУБД
Возможно, из этого получится неплохая замена memcached'у, у которого выход из строя ноды вообще приводит к потере данных.
> Возможно, из этого получится неплохая замена memcached'у, у которого выход из строя
> ноды вообще приводит к потере данных.Да, я если честно тоже другого применения не вижу. Ну возможно - пока не вижу.
с SQL интерфейсом ему и такое применение не светит
Thank you for writing this article. I do not understand the Russian language, but according to Google's Translator, you explained InfiniSQL very well.I have always enjoyed working with Russian engineers--you have very good analytical skills and are interested deeply in technology. I hope that you will contribute to the InfiniSQL project as developers, alpha customers, and in any way that you can for the community.
Please visit http://www.infinisql.org to find the code and to find how to stay in touch with the project.
Sincerely,
Mark Travis
Founder, InfiniSQL
> Клиентский интерфейс совместим с PostgreSQLПусть взлетает! Как минимум "восьмёрочники" (1Cv8) будут довольны.
Ну и вобще, чем больше движков БД, тем лучше, няхай конкурируют.
они довольны не будут, им из ACID все буковки нужны, особенно D
Да и не только они, опыт NoSQL показывает, что эта буковка вообще всем нужна в первую очередь - люди кладут на транзакционность в угоду скорости и надёжности.Так что тхе... если бы они на дисках такую производительность обеспечили - был бы прорыв, а сейчас - так, очередная in-memory БД.