Дмитрий Симоненко при поддержке компании Мail.ru подготовил второй релиз встраиваемой транзакционной СУБД Sophia (http://sphia.org/), построенной с использованием новой архитектуры (http://sphia.org/architecture.html) хранения данных, спроектированной, как ответ на недостатки LSM-деревьев (https://en.wikipedia.org/wiki/Log-structured_merge-tree). Код Sophia написан на языке Си и поставляется (https://github.com/pmwkaa/sophia) под лицензией BSD. Для работы с базами в формате Sophia доступен (https://github.com/sphia/sphia) интерфейс для работы из командной строки.Sophia относится к категории встраиваемых СУБД и поставляется в форме разделяемой библиотеки, предоставляющей API для обработки данных. СУБД рассчитана на обеспечение очень большой скорости записи и чтения при работе с данными небольшого и среднего размера. Данные сохраняются на диске с использованием лог-подобного хранилища, работающего в режиме постоянного пополнения (append-only). В отличие от других лог-подобных хранилищ, метод хранения в Sophia не ограничивается высокой скоростью записи, но также оптимизирован для обеспечения высокой скорости произвольного чтения данных и выборки диапазонов значений.
<center><a href="http://sphia.org/v12.png"><img src="http://www.opennet.me/opennews/pics_base/0_1422820069.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Отличительные особенности:
- Быстрая запись (Append-Only) и оптимизация на чтение;
- Соответствие требованиям ACID (атомарность, согласованность, изолированность, надежность);
- MVCC-движок для обеспечения одновременного конкурентного доступа к БД (Multi-Version Concurrency Control);
- Транзакции, которые могут охватывать несколько операций;
- Консистентные курсоры;
- Снапшоты;
- Возможность хранения нескольких БД в одном файле;
- Поддержка сериализированных представлений;
- Многопоточный движок и возможность использования в многопоточных приложениях;
- Поддержка создания горячих бэкапов, создаваемых на лету без приостановки работы;
- Простой API, лёгкая интеграция с приложениями, отсутствие сторонних зависимостей. Для работы требуется только два файла на языке Си.
URL: http://sphia.org/
Новость: http://www.opennet.me/opennews/art.shtml?num=41583
Встраиваемое KVS с Acid и транзакциями - это пять. Надо поприглядеться.
Интересно посмотреть нагрузочное тестирование
и желательно сравнение с монстрами
PS MSSQL монстром не считаю ..... скорее пародией на БД
Ты неправ. У него есть HandlerSocket, для k-v хранилищ гоняться с ним сложно, разве что новейший PostgreSQL. Всякие MongoDB и memcached нервно курят в сторонке.
>>PS MSSQL монстром не считаю ..... скорее пародией на БД
> У него есть HandlerSocket,Вы точно про mssql, а не про mysql?
Всегда ломал голову ну что надо маздайцам на форуме по открытым технологиям ????
Или что Вас забанили на MiCrOsOft.com ????
> Всегда ломал голову ну что надо маздайцам на форуме по открытым технологиям ????Open Source != Linux или *BSD
> для k-v хранилищ гоняться с ним сложно, разве что новейший PostgreSQL.Даешь гонки феррари и карьерных самосвалов! :)
выиграть могут как те так и другие, всё зависит от трассы. Более того можно подобрать трассу когда шансы будут примерно равны.
>и желательно сравнение с монстрамиВы хотите сравнения встраиваемой бд из двух файлов, с "монстрами"?
> Вы хотите сравнения встраиваемой бд из двух файлов, с "монстрами"?Народ просто не понимает, зачем оно. А мне вот допустим недавно понадобилось очень шустрое межсеансовое хранилище для *локальных* переменных, коих сотни тысяч штук, но с блокировками и транзакциями. Смотрю пока на sqlite3, но мне оно кажется слишком громоздким.
у sqlite изоляция транзакций serializable. и при записи блокировка ставится на всю базу. и никакого mvcc, не для этого она создавалась.
Блокировка в sqlite3 во время транзакции ставится т.н. "reserved", не "exclusive", т.е. читатели в это время могут продолжать работать. MVCC при этом в sqlite3 есть, 1W/*R. В принципе для моей задачи это вполне подходит (у меня чтение в сотни раз преобладает над записью), но KV хранилище подошло бы куда лучше.
можно обратиться к классике - BerkleyDB, или kyotocabinet.
> но с блокировками и транзакциями. Смотрю пока на sqlite3, но мне
> оно кажется слишком громоздким.Если что, скулайт на запись могет только 1 writer'а, оверхет от сиквеля никто не отменял, да и очень шустрым его назвать сложно. Если надо хранить нечто хорошо накладывающееся на логику key-value (переменная-значение по идее неплохо в это вписывается) - key-value скорее всего будет резвее и без лишней возни. Кстати бывает еще такая штука как tokyo cabinet. Помонструознее сабжа немного. Но авторы оного не зря хвастаются скоростью и прочая.
Таки перевёл систему на SQLite3. Мне у SQLite3 в моём применении не понравилось только одно: каждая транзакция вызывает генережку отдельного логфайла. Да, там есть режим "сохранять логфайл", но всё равно он как-то так с ним работает, что на shared FS (GFS2) его не разместить - дикие тормоза. Впрочем, в моём случае это не критично.
Увы, ни Tokyo, ни Kyoto Cabinet - не умеют MVCC... в моём случае нужна поддержка consistent read, и желательно без блокировки reader'ов при записи.
> Народ просто не понимает, зачем оно. А мне вот допустим недавно понадобилось
> очень шустрое межсеансовое хранилище для *локальных* переменных, коих сотни тысяч штук,
> но с блокировками и транзакциями. Смотрю пока на sqlite3, но мне
> оно кажется слишком громоздким.встраиваемыfirebird
> Вы хотите сравнения встраиваемой бд из двух файлов, с "монстрами"?Что характерно - key-value базы по скорости имеют свойство сильно втыкать SQL'ным, хотя-бы из-за отсутствия оверхеда. Но с другой стороны, выписывать сложный запрос для бизнес-аналитики самолично раскладывая все на формат ключ-значение...
>>и желательно сравнение с монстрами
> Вы хотите сравнения встраиваемой бд из двух файлов, с "монстрами"?даешь сравнение sohpia vs bdb vs kyoto cabinet! :) они встраиваемые ;)
хотя две последние не являются в полном смысле СУБД - они скорее просто БД... есть подозрение что и САБЖ тоже.
> Интересно посмотреть нагрузочное тестирование
> и желательно сравнение с монстрами
> PS MSSQL монстром не считаю ..... скорее пародией на БДЗнаете, не стоит так вот показывать свое непонимание изначальной концепции продукта.
https://ru.wikipedia.org/wiki/%D0%92%D1%...Почитайте, пожалуйста, эту ссылку и обратите внимание на особенно и сферу
> Почитайте, пожалуйста, эту ссылку и обратите внимание на особенно и сферуНу как бы чисто номинально у MS была какая-то сильно обкоцаная версия для именно встройки в приложения. Но правда у MS даже это получилось нехилым монстрятником, где никакой речи о "паре файлов на си" и близко разумеется не идет.
Понимание как раз полное
Отличие БД представляется
под словом МОНСТРЫ понималось sqlite и Berkeley
Но никак не MSSSSS
Вообщем сам сравню при случае ....
sqlite - монстр... ах-ха-ха, alexpn, что ты делаешь, прекрати.
> и желательно сравнение с монстрамиА давайте лучше сравним феррари с карьерным самосвалом? :)
Чем оно лучше LMDB из OpenLDAP?
Думаю многие не понимают что насамом деле представляет из себя LMDB и его худший случай. Дело в том, что LMDB при интенсивных обновлениях начинает переиспользование старых странниц. Со временем производительность падает до классического B-дерева на вставку (а это рандомное обращение к диску на запись + эффективность кеширования). LMDB отлично работает на базах которые не сильно больше чем оперативная память. Бенчмарки обычно отличные, потому что используется mmap и бенчмарки на смешное кол-во данных.Автор делал бенчмарк с LMDB и можете посмотреть чем это закончилось: https://github.com/pmwkaa/sophia_benchmark/issues/2
Это большая архитектурная проблема.
Спасибо большое за развернутый ответ и бенчмарк.
для интересующихся - хотя автор и удалил страницу с результатами бенчмарка, она доступна в архиве? https://web.archive.org/web/20140803103955/http://sphia.org/...
> Для работы требуется только два файла на языке Си.Странное заявление. На GitHub файлов значительно больше.
>> Для работы требуется только два файла на языке Си.
> Странное заявление. На GitHub файлов значительно больше.Похоже что там amalgamated сборка, по аналогии с sqlite. Создается новый Си-файл.
А зачем это делается? Ведь линковка десятка obj-файлов -- это ничего в сравнению с пересборкой и линковкой всех (даже если это один файл) в случае изменения одного из них. Чисто выпендриться, какие мы крутые и embedded-friendly?
Походу еще и будет под BSD-лицензией
