Доступен (https://github.com/pmwkaa/sophia/releases/tag/version_2.1) релиз встраиваемой СУБД Sophia 2.1 (http://sophia.systems/), которая поставляется в форме разделяемой библиотеки, предоставляющей API для обработки данных. Код Sophia написан на языке Си и поставляется (https://github.com/pmwkaa/sophia) под лицензией BSD.СУБД рассчитана на обеспечение очень большой скорости записи и чтения при работе с данными небольшого и среднего размера. Данные сохраняются на диске с использованием лог-подобного хранилища, работающего в режиме постоянного пополнения (append-only). В отличие от других лог-подобных хранилищ, метод хранения в Sophia не ограничивается высокой скоростью записи, но также оптимизирован для обеспечения высокой скорости произвольного чтения данных и выборки диапазонов значений.
Начиная с версии 2.1 СУБД Sophia позиционируется как гибридное RAM/Disk-хранилище, использующее для хранения как ОЗУ так и диск, и позволяющее автоматически разделять "горячие" и "холодные" данные (обновлённые и не изменявшиеся).
Поддерживаются следующие технологии:
- Дисковое хранение - для хранения используется жесткий диск или Flash-память. Запись кешируется в памяти для последующего сброса на диск.
- Анти-кеширование - оперативная память становится основным хранилищем. Холодные данные читаются с диска или Flash-памяти.- Постоянное кеширование - Второе хранилище используется в паре как LRU-кеш в оперативной или Flash-памяти для горячих данных. Холодные и горячие данные дублируются в основном хранилище.
- Постоянное хранение в памяти - данные хранятся в оперативной памяти и постоянно сохраняются на диске. Поддерживается сжатие данных в памяти.
Из других улучшений в новом выпуске можно отметить режим LRU (https://github.com/pmwkaa/sophia/blob/59c71c73d2aa056605de94...) для вытеснения старых данных из кеша, возможность раздельного сжатия "горячих" и "холодных" данных, реализация фильтра приблизительной выборки (AMQ (https://github.com/pmwkaa/sophia/blob/59c71c73d2aa056605de94...), Approximate Member Query), поддержка снапшотов для быстрого восстановления после сбоя, реорганизация операций UPSERT (https://github.com/pmwkaa/sophia/blob/59c71c73d2aa056605de94...) (добавить-или-модифицировать), новый режим восстановления целостности, дополнительные метрики для мониторинга (https://github.com/pmwkaa/sophia/blob/59c71c73d2aa056605de94...) производительности.
Основные особенности СУБД Sophia:
- Быстрая запись (Append-Only) и оптимизация на чтение;
- Соответствие требованиям ACID (атомарность, согласованность, изолированность, надежность);
- MVCC-движок для обеспечения одновременного конкурентного доступа к БД (Multi-Version Concurrency Control);
- Транзакции, которые могут охватывать несколько операций;
- Консистентные курсоры;
- Снапшоты;
- Возможность хранения нескольких БД в одном файле;
- Поддержка сериализированных представлений;
- Многопоточный движок и возможность использования в многопоточных приложениях;
- Поддержка создания горячих бэкапов, создаваемых на лету без приостановки работы;
- Простой API, лёгкая интеграция с приложениями, отсутствие сторонних зависимостей. Для работы требуется только два файла на языке Си.
URL: http://sophia.systems/
Новость: http://www.opennet.me/opennews/art.shtml?num=43727
> Быстрая запись (Append-Only) и оптимизация на чтение;база 15-20 гигов тормозить будет?
У Вас, видимо, будет.
> СнапшотыЗаинтересовался, но, к сожалению, оказалось чисто внутренней деталью реализации, а не полноценным статичным срезом данных как, например, в leveldb.
> Для работы требуется только два файла на языке Си.
А вот это бывает удобно.
Подумал, что вся СУБД состоит из 2-х файлов. Как бы не так.
В SQLite тоже много файлов, которые потом собирают в один .c. Тут аналогично, есть возможность сгенерировать единый .c файл, специально проверил.
Честно говоря ребята молодцы. Но когда тестировали у нас проиграло на чтение rocketdb.
Пользовал первую версию, было громко заявлено о скоростях и прочем. ~1000000 записей вида логин_твитера=ид_твитера и база стала весить 30ГБ и встала колом, диск лёг. Я верю, что новые версии лучше, но осадок остался.
Ну, архитектура с тех пор сильно изменилась. Уверен, сейчас будет ощутимо юзабельнее.
"встраиваемая СУБД" какие в опу 30Гб на базу? Она же не для таких вещей
У некоторых SQLite терабайтами ворочает, и они только нахваливают.
> У некоторых SQLite терабайтами ворочает, и они только нахваливают."Не верю"
SQLite это вообще чумное убожество. Хотя чего ждать от поколения твиттера и ми-ми-ми.
Как бы, у всех свои задачи.Ссылку, где я в оригинале увидел такой claim не нашёл :( . Ну вот пример другой http://www.evanjones.ca/sqlite-for-data-analysis.html
В общем, для аналитики вполне может свой хлеб отработать :) Но, понятно, OLTP на таком объёме SQLite не потянет.
Но, Sophia, уверен, несколько сот гигабайт смело потянет.
некоторые 'встраиваемые' БЫ - и побольше.
вот если бы она на 50 Терабайт была, тогда да, было бы нетипично для.
Зачем это нужно? Кто объяснит? И почему подобное называется БД коль элементарно acid-у не соответствует ни в малейшей степени? Это не БД, а просто некий механизм по оперативной работе с несущественными данными без гарантированной персистентности на уровне софта. Для тех, кто нефига не понимает, что делает.
Похоже, я погорячился. Заявлено много чего.
Вы бы еще CAP-теорему вспомнили
Э, как бы сформулировать... Никакой САР-теоремы не существует. Гетерогенные системы можно делать какими угодно, хоть согласованными всегда, хоть -- иногда. Этому никаких принципиальных препятствий нет.
Да вы батенька освежите в памяти САР-теорему, прежде чем разглагольствовать. Консистентность входит только в два из трех вариантов.
Консистентность. Это что такое? Переведите. Вы понимаете, что это значит вообще? Ещё раз, никакой "САР-теоремы" не существует. Это просто маркетинговое обоснование для убожественных систем. В результате подобной лапши, например, в РФ внедрили в одной гос. организации "распределённую NoSQL-систему документооборота" и получили, что уже заверенный кадастровый договор ещё пару месяцев болтается в различных статусах в дебрях этого очень NoSQL-решения. А на основе этих статусов пеня начисляется и всякие письма автоматом штампуются совершенно от всего этого бардака очумевшему клиенту.
Сказки клиентам выдумывать и рассказывать дело, иногда, нужное и важное. Главное -- самому случайно в них не уверовать.
САР-теорема или, например, "ортогональность реляционной модели и объектной", "разработка через тестирование" -- всё из той же оперы.
>Консистентность. Это что такое? Переведите.Перевожу на твой https://ru.wikipedia.org/wiki/Согласованность_данных
>Вы понимаете, что это значит вообще? Ещё раз, никакой "САР-теоремы" не существует.Больше нам с вами говорить смысла не имеет, я бесплатными образовательными курсами на форумах не занимаюсь.
Хотя на этом -- спасибо: что хотя бы бесплатно маразм не распространяете.
> Зачем это нужно? Кто объяснит?У тебя точно есть родной брат, тоже Кирилл.
Вот все эти мантры по in-ram processing они о чём? В общем-то, все основные СУБД с оперативными данными работают по возможности с самым быстрым устройством ввода-вывода. В чём отличие вот этого от того, что, ну, скажем, в том же Оракле? Тот тоже использует wal и отложенный сброс на диск грязных блоков, а изменения обслуживаются в рамках mvcc с согласованием по времени. Что выбирать в память тоже довольно гибко настраивается. Но почему-то оракл (ну или слона) гордо не именуют in-ram processing-ом, хотя он там в полный рост есть?
А, понятно, это же встраиваемое решение.