| 1.1, Аноним (1), 15:25, 31/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Круто, поздравляю. Хотелось бы конечно полноценной реляционной БД. Ключ/значение подходит для чего-то очень специфического.
А так интересный проект. Для Android есть что-то похожее, вроде - mmkv.
| | |
| |
| |
| 3.4, Rev (?), 16:04, 31/12/2021 [^] [^^] [^^^] [ответить]
| –5 +/– |
Вот если такое же, но ~с перламутровыми пуговицами~ на чистом Расте...
| | |
| |
| 4.8, Урри (ok), 16:50, 31/12/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Возьми и напиши. Язык ведь простой, безопасный, легко изучаемый и внутренне не противоречивый.
За недельки две осилишь, думаю.
| | |
|
| 3.9, Аноним (1), 17:07, 31/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Это медленное и с архитектурой 20 летней давности. 25мс на примитивнейшие запросы... моё почтение, это много!!!
Если весь бюджет на изменение UI максимум 100мс, включая рендеринг и все-все-все остальное.
Есть DuckDB как лучик света https://github.com/duckdb/duckdb, который превосходит во всём. И на некоторых запросах 8х раз быстрее. Но есть и но.
| | |
| |
| |
| 5.20, Аноним (1), 20:21, 31/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Нет "Persistent index structures", те индексы пересоздаются каждый раз и живут только в памяти. Наверное для анализа данных и пофиг, а для моего todo листа очень плохо, не подходит.
Те пока как полноценная замена обычной ДБ не подходит. Они, правда, в этот сегмент и не метят. Но уж очень она хороша по технологиям. Её разрабатывают эксперты мирового уровня, как я понял.
https://github.com/duckdb/duckdb/issues/693#issuecomment-646847487
| | |
| |
| 6.24, тоже Аноним (ok), 12:00, 01/01/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Например, с прекрасным правильным и перспективным языком D эксперт мирового уровня колупается уже лет двадцать. Но есть одно но...
| | |
| 6.25, x3who (?), 13:18, 01/01/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Нет "Persistent index structures", те индексы пересоздаются каждый раз и живут только
> в памяти. Наверное для анализа данных и пофиг, а для моего
> todo листа очень плохо, не подходит.
А, спасибо, не заметил. У них там какой-то другой концепт с поколоночным доступом к записям, а не по записям, может поэтому индексы в традиционном представлении там не осмысленны.
Подозреваю оно ещё не хорошо будет вести себя на изменчивых данных. Т.е. пока иы последовательно заливаешь туда статистику - всё хорошо, а если потом пришел пропущенный ранее кусок данных - тут могут оказаться проблемы.
| | |
| |
| 7.27, Аноним (1), 15:46, 01/01/2022 [^] [^^] [^^^] [ответить] | –1 +/– | Да, у них OLAP БД, а не OLTP Те заточены на аналитические запросы по всей табли... большой текст свёрнут, показать | | |
| |
| 8.38, Аноним (38), 19:45, 01/01/2022 [^] [^^] [^^^] [ответить] | +/– | Дихотомия OLAP OLTP не просто так появилась Далеко не всегда рожденный ползать... текст свёрнут, показать | | |
|
|
|
|
|
|
| |
| 3.12, erthink (ok), 18:04, 31/12/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > ну так libmdbx и есть "для чего-то специфического" (LDAP)
У libmdbx действительно плохо только с одним сценарием - когда требуется фиксировать много мелких транзакций с гарантией сохранности данных при системной аварии (потери питания и т.п.), ибо намеренно нет WAL. В остальных случаях достаточно хорошо, либо ещё лучше.
А LDAP - просто идеальный вариант, много поисков/чтений и относительно мало апдейтов.
| | |
|
| 2.11, erthink (ok), 17:45, 31/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
На всякий - libmdbx без проблем собирается под Android и iOS.
В сравнении с mmkv есть несколько принципиальных отличий:
1. mmkv это "framework", т.е. с более развесистым, гуманно-плюшевым API;
2. насколько помню в mmkv накладные расходы в 3-4 больше раза, но это не заметно на его целевых "мобильных" масштабах.
3. libmdbx может больше именно как движок хранения. Например эффективные вложенные b-tree для повторов/дубликатов в индексах. И на терабайтных базах, с которыми libmdbx "просто работает", mmkv примерно не сможет.
| | |
|
| 1.13, Аноним (13), 18:37, 31/12/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Раз уж новость от самого автора, то хотелось бы у него же и поинтересоваться, в каком состоянии сейчас находится ReOpenLDAP, и планируется ли возобновление активности по проекту?
| | |
| |
| 2.16, erthink (ok), 19:23, 31/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
> А что там с секретной SQL DB, которую автор обещал пару лет
> назад?
Уточните, что именно вы имеете в виду?
Если форк кликхауса:
- то лицензия позволяет не открывать код, а финальное решение зависит от Positive Technologies.
- в ряде продуктов уже используется, а в 2022 таковых станет больше.
- имеет собственные фичи, а в целевых сценариях использования обгоняет кликхаус, в том числе умеет больше при использовании меньших ресурсов.
Если MithrilDB, то там никогда не планировался SQL. Аналогично с libfpta, но эта либа давно в production и доступна публично.
Если о приземлении SQLite на libmdbx, то это не ко мне, а сюда https://github.com/LumoSQL/lumosql/issues/4
| | |
| |
| 3.21, Аноним (1), 20:24, 31/12/2021 [^] [^^] [^^^] [ответить]
| +/– |
Понял, спасибо. Я о MithrilDB, думал это будет реляционная БД с SQL, замена SQLite
| | |
|
|
| |
| 2.19, erthink (ok), 20:13, 31/12/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> как на счет sophia?
Не совсем понятно что вы хотите услышать, но для информации:
- это LSM, который Дмитрий делал (насколько мне известно) для Тарантула;
- разработка Sophia остановлена ~5 лет назад;
- еще до ухода Константина по-мотивам был сделан Vinyl, одна из основных фишек которого - глубока интеграция с тарантулом и одновременная фиксация транзакций от большого кол-ва клиентов.
| | |
|
| |
| 2.49, Аноним (49), 16:26, 04/01/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> gnu recutils
а при чем тут эта шняга уровня ini-файлов?
даже не bdb.
| | |
|
| 1.28, adolfus (ok), 17:31, 01/01/2022 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
 Чтобы называться базой данных, нужно, как минимум, поддерживать вторичные ключи, транзакции и временные блокировки вдоль и поперек таблиц.
И это, как его... AIDC -- вот!
| | |
| |
| 2.34, Аноним (38), 18:50, 01/01/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> Чтобы называться базой данных, нужно, как минимум, поддерживать вторичные ключи, транзакции и временные блокировки вдоль и поперек таблиц.
Как насчет СУБД Redis, где нет даже таблиц?
| | |
| |
| 3.35, adolfus (ok), 19:04, 01/01/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Чтобы называться базой данных, нужно, как минимум, поддерживать вторичные ключи, транзакции и временные блокировки вдоль и поперек таблиц.
> Как насчет СУБД Redis, где нет даже таблиц?
До СУБД этому редису, как до Луны раком. То, что умеет редис, я сделаю на c++11 и будет оно в разы быстрее, жрать памяти будет меньше и при этом не будет называться СУБД. Мало того, в дополнение к базовому функционалу будет поддерживаться isam в ключе.
| | |
| |
| 4.37, Аноним (38), 19:42, 01/01/2022 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> То, что умеет редис, я сделаю на c++11 и будет оно в разы быстрее, жрать памяти будет меньше
Возможно, вам стоит сменить ник на "Лев Николаевич"?
| | |
| |
| |
| 6.47, adolfus (ok), 09:57, 04/01/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> Не, пусть лучше сделает.
Ага, мы тут десятилетиями ждали, когда-же редис изволит появиться.
| | |
|
|
|
|
| 2.52, erthink (ok), 17:49, 04/01/2022 [^] [^^] [^^^] [ответить]
| +/– |
Пожалуйста RTFM, транзакции и ACID в libmdbx есть.
Таблиц и вторичных ключей в key-value не должно быть по определению, но может быть надстроено (см. libfpta).
Блокировки нужны там "где они нужны", но в целом это лишь путь решения одних проблем ценой получение других.
В libmdbx намеренно полная сериализация для пишущих транзакций и примерно lockfree для читателей.
Собственно за счет этого в libmdbx существенно меньше накладных расходов, что позволяет получить в целевых сценария использования производительность на несколько порядков больше условного оракла.
Поэтому, например, возможно сделать Akula (самый быстрый клиент Ethereum).
Тем не менее, критику по поводу корректности использования терминов "база данных" и "СУБД" просьба начинать с первоисточников:
https://en.wikipedia.org/wiki/Database
https://ru.bmstu.wiki/LMDB_(Lightning_Memory-Mapped_Database)
и т.д.
| | |
|
|
