Состоялся (https://groups.google.com/forum/#!topic/sophia-database/asQx...) релиз встраиваемой СУБД Sophia 2.2 (http://sophia.systems/), оформленной в виде разделяемой библиотеки. СУБД рассчитана на обеспечение очень большой скорости записи и чтения при работе с данными небольшого и среднего размера. Данные сохраняются на диске с использованием лог-подобного хранилища, работающего в режиме постоянного пополнения (append-only). В отличие от других лог-подобных хранилищ, метод хранения в Sophia не ограничивается высокой скоростью записи, но также оптимизирован для обеспечения высокой скорости произвольного чтения данных и выборки диапазонов значений. Код Sophia написан на языке Си и поставляется (https://github.com/pmwkaa/sophia) под лицензией BSD.Ключевыми изменениями в Sophia 2.2 являются новые схема хранения и архитектура хранения. Новая схема хранения базируется на построчном размещении, при котором каждая строка включает ряд полей произвольного типа. Подобный подход позволяет снизить накладные расходы при размещении данных в хранилище, например, числа и метадданые могут хранится в более компактном представлении непосредственно в строках (rows). Кроме того, новая схема позволят организовать работу со вторичными индексами. Что касается новой архитектуры хранения, то её основной особенностью является обеспечение постоянной производительности операций чтения, записи и сканирования диапазонов, не зависящей от размера хранилища (O(1)).
Основные особенности СУБД Sophia:- Быстрая запись (Append-Only) и оптимизация на чтение;
- Соответствие требованиям ACID (атомарность, согласованность, изолированность, надежность);
- MVCC-движок для обеспечения одновременного конкурентного доступа к БД (Multi-Version Concurrency Control);
- Транзакции, которые могут охватывать несколько операций;
- Консистентные курсоры;
- Снапшоты;
- Возможность хранения нескольких БД в одном файле;
- Поддержка сериализированных представлений;
- Многопоточный движок и возможность использования в многопоточных приложениях;
- Поддержка создания горячих бэкапов, создаваемых на лету без приостановки работы;
- Простой API, лёгкая интеграция с приложениями, отсутствие сторонних зависимостей. Для работы требуется только два файла на языке Си.
- Поддерживаемые технологии хранения:
- Дисковое хранение - для хранения используется жесткий диск или Flash-память. Запись кешируется в памяти для последующего сброса на диск.- Анти-кеширование - оперативная память становится основным хранилищем. Холодные данные читаются с диска или Flash-памяти.
- Постоянное кеширование - Второе хранилище используется в паре как LRU-кеш в оперативной или Flash-памяти для горячих данных. Холодные и горячие данные дублируются в основном хранилище.
- Постоянное хранение в памяти - данные хранятся в оперативной памяти и постоянно сохраняются на диске. Поддерживается сжатие данных в памяти.URL: https://groups.google.com/forum/#!topic/sophia-database/asQx...
Новость: https://www.opennet.ru/opennews/art.shtml?num=44977
Это аналог SQLite?
нет, это key-value бд.
это скорее дальний родич беркли дб, чем склайт. без блэкджека и проблем лицензионных но зато с минимизированным оверхэдом на эксплуатацию и упрощенной интеграцией на прикладном уровне.
те для тех кому эрацев вроде d-ets маловато )
Слава Вселенной, что оно не на каком-то Rust или Go.
Позвольте поинтересоваться, а чем обусловлена такая реакция к Rust? Просто интересно мнение людей, что не устраивает, например синтаксис, система лайфтаймов, владения и заимствования, либо же система типов? Вопрос не ради холивара! Просто интересно мнение инженеров.
Такая реакция на Rust обсусловлена в первую очередь сектой расто-манов, которые заполонили уже все интернеты своими хэлло ворлдами.
Rust-оманов значительно меньше чем Go-внюков. Вторые реально всю вселенную хотят на своем любимом язычке переписать.
И правильно. Знаете почему? Мне очень интересно: почему бы и нет?
Потому что существует 1. ДОСТУПНАЯ, 2. понятная, 3. официальная, 4. постоянно обновляющаяся документация. Да-да. Надеюсь те, у кого есть уважение к своему времени, перейдут на RUST & GO...
Ага, вообще, уважение к себе в целом и полностью. Поддерживаю.
От главы Lifetime в Rust Docs хочется глаза вырвать, настолько она замечательная
С каких это пор читать man-ы наши небесные стало грешно?
На Go уже написан Docker (считай, новый продукт). На Rust _переписывают_ GNU coreutils: https://github.com/uutils/coreutils И кто тут переписывает вселенную?
И в чём проблема? Нормальный тестовый проект для развивающегося языка.
Вообще не понимаю хейтеров. Как будто их заставляют переписывать на Rust, например, тот же coreutils =)
Их не заставляют переписывать.
Их заставляют продираться сквозь информационный шум, создаваемый поклонниками Go и Rust на каждом углу. Каковой в подавляющем большинстве случаев не несет с собой даже толики полезного сигнала. Если бы в этом шуме встречались хотя бы какие-то проекты где действительно применение каких-то интересных возможностей этих языков давало что-то полезное - в плане ли скорости разработки, надежности ли, безопасности ли, еще чего-то - что позволило бы реализовать какие-то полезные вещи, которые сложно, долго, неудобно было бы реализовать с использованием других языков.Посмотрите рядом топик про недо-monit на Go. Всё то же самое можно было бы сделать, например, на Perl - причем гораздо быстрее, спасибо CPAN - и точно так же запаковать одной из утилит в один файл без зависимостей. В сэкономленное время можно было бы добавить какой-то интересный функционал или хотя бы посмотреть что и как сделано в monit и подумать зачем оно так сделано - и даже написать об этом что-то интересное и может быть реализовать у себя какие-то подходы, которые еще лучше. Но это скучно, поэтому будем писать на Go и Rust велосипеды с одним квадратным колесом и заполонять ими все интернеты.
> На Go уже написан Docker (считай, новый продукт). На Rust _переписывают_ GNU coreutils: https://github.com/uutils/coreutils И кто тут переписывает вселенную?Хуже, на расте даже ОСь накатали!
https://www.redox-os.org/
И работает она даже на реальных железках:
https://www.redox-os.org/screens/
Причем, в ходе разработки авторы раста прислушивались к разработчику насчет желательных фич языка, вылезающих граблей и т.д. Даже вкатили https://github.com/rust-lang/rust/pull/32410
А что там с Go, который вроде бы тоже c претензией на "системное программирование"? )
У Go действительно были такие претензии?
https://golang.org/doc/faq
> Go was born out of frustration with existing languages and environments for systems programming.https://github.com/golang/go/wiki/GoForCPPProgrammers
> Go is a systems programming language intended to be a general-purpose systems language, like C++.
Одно слово - docker
>> Просто интересно мнение инженеровЧтобы узнать мнение инженеров, нужно спрашивать инженеров?
Под всем этим гайном, типа лайфтаймов, этого вашего владения и заимствования, лежит системная архитектура (СА), с которой даже на C не всегда получается эффективно повзаимодействовать, несмотря на то, что и СА и C -- суть абсолютно процедурные сущности. В связи с этим встает вопрос -- а нахрена выдумывать непроцедурные костыли и велосипеды, если в "отрасли" есть сотни и тысячи выверенных паттернов, которые можно эффективно реализовать на любом процедурном языке, в том чисел и C?
O(1) оно только
- в идеальной сферической в вакууме машине Фон Неймана с единой ценой доступа к любой ячейке памяти
- если оторвать MVCC (иначе раскатистое эхо от длинной очереди откатывающихся транзакций можно слушать при некоторых условиях довольно долго)
- без http://sophia.systems/v2.1/admin/compaction.html
Я сейчас не про твою критику Софии спрошу. Она частями разумна.
(поправлю только, что O(1) - имелось в виду обращений к диску, а не вычислительных затрат).Я спрошу: неужели ты себя настолько не ощущаешь личностью, что не смог подобрать псевдоним, не ассоциированный с реальным человеком?
PS. если ты действительно Rob Pike, то приношу прощения.
PPS. да, мой псевдоним тоже мало хорошего говорит обо мне :-)
"O(1) - имелось в виду обращений к диску, а не вычислительных затрат"так и запишем - в новости ложь.
PS
Я спрошу: неужели ты себя настолько не ощущаешь личностью, что не смог подобрать псевдоним, не ассоциированный с реальным человеком?PPS. если ты действительно Funny Falcon, то приношу прощения.
PPPS. да, мой псевдоним тоже мало хорошего говорит обо мне :-)
> PPS. если ты действительно Funny Falcon, то приношу прощения.Я действительно funny_falcon. Я не слышал ни о ком в it-сообществе, кто тоже бы использовал этот ник-нейм. Хотя, мне кажется попадался фотограф из Америки.
> Я сейчас не про твою критику Софии спрошу. Она частями разумна.В каких же частях она *не* разумна? Это интереснее всего.
> (поправлю только, что O(1) - имелось в виду обращений к диску, а
> не вычислительных затрат).Это уже ближе к реальности. А что же с compaction? Он как учитывается в этой формуле? "Имелось в виду что 1 - это не совсем 1, а внутри него есть еще некоторое C"?
> Я спрошу: неужели ты себя настолько не ощущаешь личностью, что не смог
> подобрать псевдоним, не ассоциированный с реальным человеком?Ощущать себя - это не настолько важное "дело всей жизни" как ныне принято считать.
>> Я сейчас не про твою критику Софии спрошу. Она частями разумна.
> В каких же частях она *не* разумна? Это интереснее всего.
>> (поправлю только, что O(1) - имелось в виду обращений к диску, а
>> не вычислительных затрат).
> Это уже ближе к реальности. А что же с compaction? Он как
> учитывается в этой формуле? "Имелось в виду что 1 - это
> не совсем 1, а внутри него есть еще некоторое C"?Log(2^48) = 48 (если по основанию 2)
А диск медленнее памяти в 1000 раз (среднестатистический ssd, диск ещё медленнее в 1000 раз).
Потому, если база, не влезающая в память, имеет O(1) обращений к диску и O(log N) поиск в памяти, то это в пределах нашей реальности можно округлить до сложности O(1).compaction не блокирует ни запись, ни чтение в sophia.
Кроме того, в отличии от потомков leveldb, здесь compaction происходит гораздо меньшими кусочками данных, и потому не производит катастрофических пауз в десятки секунд.Хотя, безусловно, оно будет нагружать диск.
>> Я спрошу: неужели ты себя настолько не ощущаешь личностью, что не смог
>> подобрать псевдоним, не ассоциированный с реальным человеком?
> Ощущать себя - это не настолько важное "дело всей жизни" как ныне принято считать.Как бы, если не ощущаешь себя, то вообще не живёшь.
"Ощущать себя" - не является достаточным условием, но является необходимым.
Если бы compaction здесь был *еще хуже* чем в LevelDB, то и смысла обсуждать бы не было. Проблемы LevelDB, впрочем, этим не ограничиваются, but I digress.При округлении логарифмов советую посмотреть в сторону NVMe, их, знаете ли, уже в ноутбуки и планшеты ставят. А также не забыть указывать, о какой именно странице памяти речь - впрочем, об этом я говорил в самом первом пункте.
> можно округлить до сложности O(1)
Вы не задумывались, почему в учебниках по алгоритмам так не делают? Так очень много чего было бы "округлить".
> не производит катастрофических пауз
На тех паттернах нагрузки, которые "имелись в виду"? На следующей итерации нашей беседы мы сможем выяснить какие же это паттерны? Что же с другими, которые в виду "не имелись"?
> безусловно, оно будет нагружать диск
Не зависит ли эта нигде не учтенная compaction-нагрузка на диск от операций с БД? А если зависит, то где же эта зависимость в красивой формуле "О(1)"?
> если не ощущаешь себя, то вообще не живёшь
Изложите, пожалуйста, подробней вашу философскую концепцию жизни.
> При округлении логарифмов советую посмотреть в сторону NVMe, их, знаете ли, уже
> в ноутбуки и планшеты ставят. А также не забыть указывать, о
> какой именно странице памяти речь - впрочем, об этом я говорил
> в самом первом пункте.http://www.3dnews.ru/917044 - 440000IOP/s на чтение. Быстрее сходу не гуглится.
Подозреваю, что это для pipeline-d (или multithreaded, если вам так понятнее) запросов.
Т.е. латенси там будет явно больше 2000ns. Судя по другим бенчам, типичным будет 10000ns.
Память - 60-100ns. Ок, не в 1000 раз, а в 100.
Но и sophia в памяти держит не все ключи, а малую часть. Так что, можно договориться про
коэффициенты 100 (чтение с диска) и 32 (работа в памяти).>> можно округлить до сложности O(1)
> Вы не задумывались, почему в учебниках по алгоритмам так не делают? Так
> очень много чего было бы "округлить".Делают. В последних параграфах, где даются советы по практической реализации.
Типичный совет:
"обращайте внимание на размер ваших данных, и константы, прячущиеся за O. Зачастую, O(N^2) бывает быстрее, чем O(log N), а O(1) - медленнее">> не производит катастрофических пауз
> На тех паттернах нагрузки, которые "имелись в виду"? На следующей итерации нашей
> беседы мы сможем выяснить какие же это паттерны? Что же с
> другими, которые в виду "не имелись"?Ты уже казуистикой занимаешься.
>> безусловно, оно будет нагружать диск
> Не зависит ли эта нигде не учтенная compaction-нагрузка на диск от операций
> с БД? А если зависит, то где же эта зависимость в
> красивой формуле "О(1)"?Нет, не зависит. Но тебе плевать на это.
>> если не ощущаешь себя, то вообще не живёшь
> Изложите, пожалуйста, подробней вашу философскую концепцию жизни.Зачем? Тебе же всё равно.
Ты - не ты, и тебе на себя наплевать, раз чужое имя носишь, и во всеуслышание говоришь, что это не главное.
Если тебе на себя наплевать, то почему мне должно казаться, что тебе на меня не наплевать, и на мою "философскую концепцию жизни"?
80 000 ns это обычный NVMe SSD.
10 000 ns это 3D XPoint.
1 000 ns это NVDIMM.
100 ns это RAM.
Про NVMe over Fabrics пока не будем.Если в ваших учебниках не дается анализ худшего случая это не очень хорошие учебники.
Если вы считаете что количество compaction в LSM-структурах данных не зависит от данных, вы считаете неверно.
Если вы считаете что compaction в современных LSM-структурах данных не является ключевым фактором, влияющим на их производительность, вы считаете неверно.То что не только первоначальная эйфория, связанная с LSM, но и вторая волна - подход "достаточно снизить compaction frequency и свести большинство этой деятельности к hot data key-ranges" - уже остались в прошлом, вы не заметили.
Вам нравится что вам не наплевать что Аноним в интернетах о вас думает?
> 80 000 ns это обычный NVMe SSD.
> 10 000 ns это 3D XPoint.
> 1 000 ns это NVDIMM.
> 100 ns это RAM.
> Про NVMe over Fabrics пока не будем.:-) убедили. Если у вас столько денег, что вы сотнигигабайтные хранилища на NVDIMM строите, то вы правы.
> Если в ваших учебниках не дается анализ худшего случая это не очень
> хорошие учебники.Учебники советуют рассматривать реальные случаи, когда дело доходит до реализации. Если худший случай реален, то его нужно рассматривать.
> Если вы считаете что количество compaction в LSM-структурах данных не зависит от
> данных, вы считаете неверно.Согласен, даже в Софии частота compaction зависит от объема и рандомности записи.
> Если вы считаете что compaction в современных LSM-структурах данных не является ключевым
> фактором, влияющим на их производительность, вы считаете неверно.Согласен, когда диск нагружен, чтение и запись страдают. Они остаются O(1) от количества данных (для софии), но константа подрастает.
Можно сказать, что появляется завсисимость от интенсивности и характера запросов/нагрузки. Но от количества данных остается прежним.> То что не только первоначальная эйфория, связанная с LSM, но и вторая
> волна - подход "достаточно снизить compaction frequency и свести большинство этой
> деятельности к hot data key-ranges" - уже остались в прошлом, вы
> не заметили.Вот здесь софия придерживается иной стратегии: чаще, но меньшими фрагментами.
Это как разные GC: одни чистят много за раз, с большой задержкой, но максимально быстро.
Другие меньшими кусочками и с минимальными задержками.Понятно, что чем больше мусора производится, тем медленнее вся система.
Но в целом, получается лучше, чем альтернативы.В общем, правда, что серебрянной пули нет.
Есть сюрекен, арбалетная стрела, метательный топор и бумеранг. Каждый для своей цели, стрелка и обстоятельств применения.> Вам нравится что вам не наплевать что Аноним в интернетах о вас
> думает?Мне нравится, что мне не наплевать на себя.
NVDIMM пока позиционируется не столько для самого хранилища, сколько для индексов.Учебники, хорошие, советуют рассматривать худшие и лучшие случаи для того чтобы определить является ли ваш случай подходящим для того или иного алгоритма.
> Согласен, даже в Софии частота compaction зависит от объема и рандомности записи.
Невероятный прогресс, всего за полдесятка итераций.
> Согласен, когда диск нагружен, чтение и запись страдают
Потрясающе, кто бы мог подумать.
> константа подрастает
Через сколько итераций мы выясним что на некоторых паттернах эта константа начинает закрывать собой Эйфелеву башню?
> Можно сказать, что появляется завсисимость от интенсивности и характера запросов/нагрузки
Но можно, разумеется, и не говорить. А продолжать рассказывать про О(1). Ведь в случае с огромным количеством данных и одним запросом в месяц это действительно будет так.
> Понятно, что чем больше мусора производится, тем медленнее вся система.
Нет, непонятно.
Всё зависит от того как именно он производится, какую структуру имеет, и как именно собирается. Легко найти случаи когда система, производящая больше мусора будет быстрее чем производящая меньше.> Но в целом, получается лучше, чем альтернативы.
Нет, не получается. А выражение "в целом" требует расшифровки, подробной и внятной.
> В общем, правда, что серебрянной пули нет.
Замечательно что потребовалось так мало времени чтобы это выяснить.
> NVDIMM пока позиционируется не столько для самого хранилища, сколько для индексов.Уууу. Понятно. Т.е. все таки, когда нашли где читать, потом опять идти в медленный сторадж. София так и делает, только индекс держит в еще более дешевой DIMM.
> Учебники, хорошие, советуют рассматривать худшие и лучшие случаи для того чтобы определить
> является ли ваш случай подходящим для того или иного алгоритма.Разве я сказал иное? Лучшие и худшие реальные случаи. Если массив чисел никогда не бывает больше десяти элементов, то insertion sort быстрее quick sort, и linear scan быстрее binary search.
>> Согласен, даже в Софии частота compaction зависит от объема и рандомности записи.
> Невероятный прогресс, всего за полдесятка итераций.Но не от объема данных. А ведь именно это подразумевается в O(1). Знаток книжек по алгоритмам должен пользоваться терминологией правильно.
>> Согласен, когда диск нагружен, чтение и запись страдают
> Потрясающе, кто бы мог подумать.Епта. Я еще на первой итерации это упомянул. Но ты слишком напыщен, чтобы поеимать, что тебе отвечают.
>> константа подрастает
> Через сколько итераций мы выясним что на некоторых паттернах эта константа начинает
> закрывать собой Эйфелеву башню?Ты опять путаещь зависимость от объема данных, и от интенсивности запросов. Плохо для знатока терминологии.
>> Можно сказать, что появляется завсисимость от интенсивности и характера запросов/нагрузки
> Но можно, разумеется, и не говорить. А продолжать рассказывать про О(1). Ведь
> в случае с огромным количеством данных и одним запросом в месяц
> это действительно будет так.Но комментс.
>> Понятно, что чем больше мусора производится, тем медленнее вся система.
> Нет, непонятно.
> Всё зависит от того как именно он производится, какую структуру имеет, и
> как именно собирается. Легко найти случаи когда система, производящая больше мусора
> будет быстрее чем производящая меньше.Конечно, если производящая меньше изначально не эффективна. Это тоже самое, что и наш с тобою разговор про сложность алгоритмов, и лучший/худший случай.
>> Но в целом, получается лучше, чем альтернативы.
> Нет, не получается. А выражение "в целом" требует расшифровки, подробной и внятной.С тобою даже пельмени в целом не получатся.
>> В общем, правда, что серебрянной пули нет.
> Замечательно что потребовалось так мало времени чтобы это выяснить.Ну ни фига ж себе. Как будто я где-то утверждал, что она есть.
>То что не только первоначальная эйфория, связанная с LSM, но и вторая волна - подход "достаточно снизить compaction frequency и свести большинство этой деятельности к hot data key-ranges" - уже остались в прошлом, вы не заметили.Где посмотреть, что сейчас придумали вместо?
Не "вместо", в дополнение к прошлым ухищрениям. Поиски что бы такого с LSM сделать чтоб оно всё-таки не так тормозило продолжаются. Про "вместо" никому неинтересно, в моде только LSM.
в б-ве юзеркейзов проще юзать вещи вроде LMDB в проектах, где изящно обошли проблемы "мысля вне коробки", во многом. пусть там и более скромная(изначально)функциональность.
В LMDB своих причуд хватает - на уровне технического исполнения, так что лучше форк https://github.com/ReOpen/libmdbx
ну, безупречных вещей нет и LMDB использована сугубо "для примера". но это в б-ве случаев - Хорошая штука и она реально РАБОТАЕТ.
это больше от Подхода к созданию проектов зависит и Идеологии, Опыта.
кому-то беркли, кому-то LMDB, кому-то redis а кому-то вообще mnesia или касандра и прочие гиппопотамы.
Работает, когда не не работает[1]. LevelDB тоже работает при определенных обстоятельствах[2]. При большом везении работает даже Cassandra[3], Redis[4] и MongoDB[5]. Про Mnesia спросите эрлангистов, лучше непублично, они расскажут почему ей никто не пользуется. BerkeleyDB пытались заставить работать уже столько поколений, что цензурно о ней сложно говорить.[1] https://github.com/ReOpen/ReOpenLDAP/issues/1
[2] https://twitter.com/alexeyraga/status/729087004806242304
[3] https://aphyr.com/posts/294-jepsen-cassandra
[4] https://aphyr.com/posts/283-jepsen-redis
[5] https://engineering.meteor.com/mongodb-queries-dont-always-r...И перестаньте писать идеологию и опыт с большой буквы.
> При большом везении работает даже Cassandra[3], Redis[4] и MongoDB[5]. Про Mnesia
> спросите эрлангистов, лучше непублично, они расскажут почему ей никто не пользуется.
> BerkeleyDB пытались заставить работать уже столько поколений, что цензурно о ней
> сложно говорить.Да, всё вышеперечисленное - работает. Ты просто рукожопый гуманитарий на ставке у опеннета.
зря вы так. куча проектов на все этом есть.
те что на редис - я даже подпиливал порой за деньгу, когда-то.
а про мнезию - это в эмбеддовке, специфический рынок и специфические кадры этим заняты, что никто не в курсе - нормально. страшнее только авиаторы и военка в этом плане и непрозрачнее.
А что из существующих реализаций самое продвинутое? Чтобы код можно было посмотреть.
Поправляюсь:
"Ощущать себя" - не является достаточным условием, но является необходимым.
Как оно в сравнении с rocksdb?
Вторичные индексы это хорошо, когда они действительно заработают
Чем оно отличается от BerkeleyDB?
> Чем оно отличается от BerkeleyDB?можно крутить хранение данных Явно в отличие от, двигая между подходами принудительно.
нету проблем лицензионных(оркаль и ко).
медленее.
а так - набор фич таки-разный, Если вчитываться.
и таки-да, беркли чуть пошустрее, но учитывая разницу в динамике развития я бы не сильно расчитывал что это надолго.
Автору благодарности
А для C# у них обёртка есть? Вижу только для джавы и хипстерских руби-питонов.
> А для C# у них обёртка есть? Вижу только для джавы и
> хипстерских руби-питонов.C# еще более хипстерский, внезапно.
C# не может быть более хипстерским, потому что у него есть компилятор, в том числе и в нэйтив код. А питоновские скриптики - это баловство для школьников, которое по некоторому недоразумению слишком часто стало применяться в крупных проектах.
> C# не может быть более хипстерским, потому что у него есть компилятор,
> в том числе и в нэйтив код. А питоновские скриптики -
> это баловство для школьников, которое по некоторому недоразумению слишком часто стало
> применяться в крупных проектах."компилятор как показатель" не работает. тк он есть у всего почти. и у бидона есть компиляторы и у жабы и у эрланга. даже для хаскеля с пэхэпэ делали, но недоделали.