выбирай, анонимус разрешает.

Почему, кстати, не банальный редис?

+

https://www.yugabyte.com/

Ого. А можно узнать что дали результаты гугла?

Редис неудобно реплицируется.

Не претендуя на звание лучшего собаковода...

Я бы взял Oracle Embedded, в девичестве Berkeley DB. Как оно с go, я без понятия, но с С, С++, Java на отлично, к python биндинг, вроде, тоже должен быть. Там в этой базе много вкусностей и полезностей.

Рекомендую, в общем.

Badger какой-нибудь можешь потыкать. Сам, правда, не использовал, но на первый взгляд внушает.

Так ему же еще репликация нужна судя по всему из коробки

Закастуй i-rinat, он емнип что-то искал.

Не нашёл.

И ещё плевался на упомянутую в треде BerkeleyDB. Когда я узнал, что вместо исправления внезапных внутренних блокировок они предлагают запускать специальную утилиту, которая по хитрому алгоритму грохает процессы, подвисшие в недрах BerkeleyDB, я понял, что это слишком энтерпрайзно для меня.

Смотрел на mysql HandlerSocket? Я не использовал, но вроде выглядит интересно

etcd

ScyllaDB

Не нашёл.

По lmdb что-то скажешь?

Использовал для доступа из нескольких процессов. Проблем не возникло. Если выключить fsync’и, которые включены по умолчанию, то быстро. Из неожиданностей вспоминается только небольшая особенность с открытием нескольких экземпляров одной и той же таблицы. Возвращается тот же идентификатор, который закрывать нужно не столько раз, сколько открывал, а только один. Но справедливости ради нужно отметить, что об этом в первом же абзаце про mdb_dbi_open написано, а я плохо читал. В остальном — всё очень приятно. Есть привязка к питону. Да и вообще к чему только привязок не наклепали. Отличный проект.

Репликации там нет. По крайней мере, не было, когда я смотрел. Для этого нужно прикручивать что-то поверх.

Наш сисадмин хвалил мейлрушный тарантул. Но мы его не используем и использовать не будем, потому что oracle - это лучшая субд, зачем нужно что-то еще, если есть oracle+delphi и т.д. А еще в oracle можно сделать key:value таблицу.

libmdbx никто ещё не предлагал? Использовал пару раз, вроде бы неплохая штука.

Офигенные требования, ТС.

Сразу видно, зачем тебе именно key-value, какие требования по производительности, реплицируемости и пр.

Можно вообще взять нормальную СУБД с репликацией и в ней key-value.

А так люди правильно советуют, удобно или нет, но Redis самый простой имхо.

Дальше копать Tarantool.

Вот тоже та же мысля про тарантул...

Похоже, в мыле одержимы NIH-синдромом.

С bdb можно горя хапнуть. Всё таки, это in-process database, а не выделенный сервер. Но проблема с внутренними блокировками, описанная в треде, вызвала лёгкое недоумение.

Вообще-то, в доках на bdb явно сказано что bdb производит блокировку на уровне страниц, а не записей (records). Т.е., если пошли внутренние блокировки, то это явно говорит о том, что размер страницы подобран некорректно. Разрулить внешним утилем можно, но... Может, софт нормально написать и для начала подумать что блочим (и как блочим), а что нет.

В противовес «большим СУБД» здесь и транзакции и репликация и можно делать шифрованные бд (AES, но его хватает), можно даже работать с in-memory db. Т.е., вся бд в памяти. Курсоры есть, поддержка многопоточности искаропки, ... В общем, зачем тарантул, я без понятия. Видимо, много лишнего времени и денег.

Не уверен насколько это всё ынтерпрайзно, но тот же OpenLDAP использует bdb как один из бекэндов для своей базы (иной раз на хер не нужно вкрячивать мускуль или постгрес для решения простейших задач), эта же СУБД используется вообще в ряде продуктов. В том же постфиксе. Но если кому-то нужен ещё и секс с отдельным сервером СУБД, то почему бы и нет?

В общем, сервера нет, sql нет, но для задач, не требующих ни того, ни другого, вполне-вполне.

Как-то вот так...

UPD. Причём, говоря о bdb, надо заметить что сырцов там на ~40М, но сама либа (если для С, в чистом виде), то порядка 350К. На всё-про всё. Линковать можно и статикой и динамикой.

Как оно с питоном или голангом будет, не в курсе, врать не буду.

Embedded

И что, там репликация есть?

зачем нужно что-то еще, если есть oracle+delphi

Это какая-то эпичная толщина, я в замешательстве.

Плюсую etcd.

Red Hat использует и продвигает etcd, используй и ты.

Ретроград!
Если что, я тоже за
BDB

Не ретроград...

А старовер. =)))

Есть. Мамой клянусЪ! =)))

https://docs.oracle.com/cd/E17276_01/html/programmer_reference/rep.html

Прикольно, а я думал, оно примитивное.

Да.

Достаточно развитая штука. Причём, удивляет размер кодовой базы. Не такой и большой, если честно.

Это какая-то эпичная толщина, я в замешательстве.

Я тоже не знаю что сказать, когда другой мой коллега начинает так говорить. Я думал, что я 5 лет на ЛОР я смогу развести срач с чего угодно, а тут каждый раз чувствую себя слабым и беспомощным.

Я бы взял Oracle Embedded, в девичестве Berkeley DB.

Лучше сразу в голову, чем в ногу, а потом в голову )

> Вот тоже та же мысля про тарантул...
Похоже, в мыле одержимы NIH-синдромом.

Уж извините за резкость, но IMHO примерно невежество. Начиная с того что Тарантул не NIH, а большой проект с другими целями и результатами. Ну и дизайн Тарантула на голову-две выше редиски. А причины относительной не-популярности в том что «уже был redis» и «эти чертовы русские тут что-то замышляют».

Если нужна репликация и key-value, то очень вероятно что именно https://www.tarantool.io/ru/

С bdb можно горя хапнуть. Всё таки, это in-process database, а не выделенный сервер. Но проблема с внутренними блокировками, описанная в треде, вызвала лёгкое недоумение.

Я бы свел к тезису, что использование Berkeley DB == BDSM ;)

Не уверен насколько это всё ынтерпрайзно, но тот же OpenLDAP использует bdb как один из бекэндов для своей базы (иной раз на хер не нужно вкрячивать мускуль или постгрес для решения простейших задач), эта же СУБД используется вообще в ряде продуктов. В том же постфиксе. Но если кому-то нужен ещё и секс с отдельным сервером СУБД, то почему бы и нет?

20 лет доедать кактус - это как-раз кроваво-ынтерпрайзно ;)

OpenLDAP использовал Berkekey DB потому-что другого не было. Даже были попытки прикрутить SQL (back-sql) и MySQL (back-ndb). В итоге Говард Чу (Howard Chu) примерно 10 лет назад взялся и сделал LMDB (и уже три года как есть libmdbx). Сейчас bdb не рекомендуемый бэкенд для TLDR-любителей, и postfix давно идёт тем-же путём.

В общем, сервера нет, sql нет, но для задач, не требующих ни того, ни другого, вполне-вполне. Как-то вот так...

Да, но... Всё-таки не понятно - нужна репликация или нет. Если нужна и/или хочется гошечки с питончиком - то лучше тарантул. Если репликация НЕ нужна и требуется производительность, то я бы выбирал между libmdbx/libfpta и RocksDB.

UPD. Причём, говоря о bdb, надо заметить что сырцов там на ~40М, но сама либа (если для С, в чистом виде), то порядка 350К. На всё-про всё. Линковать можно и статикой и динамикой.

Уж да, кактус разросся. Но плотность ошибок там всё та же = не менее 1 на 100 кб исходников. Поэтому на 350К бинарника около 500-1000 багов. Короче, DBSM ;)

Спасибо. Посмешили... =)))

Уж извините за резкость, но IMHO примерно невежество.

Да всё нормально. =))) Но ведь я же Вас за язык не тянул, верно? =)))

Начиная с того что Тарантул не NIH, а большой проект с другими целями и результатами. Ну и дизайн Тарантула на голову-две выше редиски.

Скажите, а взять и создать хранилище key-value, прикрутив к нему lua (зачем?) и sql... Вам это ни чего не напоминает? Шутки про лунный модуль, блекджек и шлюх ещё в треде не было? По-моему, самое время... =)))

Ну я ещё могу понять sql, хотя он и вносит определённые задержки, т.к. его как минимум распарсить надобно, но... lua? Оно-то тут зачем? Впрочем, барин знает что с кобылой делать, наше дело хвост держать. =))) Не сомневаюсь что последний пассаж про барина и кобылу Вы по достоинству оцените. =)))

Т.е., по данному пункту можно сделать несколько выводов. Во-первых, у Вас дислексия. Если бы её не было, Вы бы заметили что лично я про редис ни чего не писал. Как минимум потому, что вот редис уж точно это не для поставленной ТС задачи. Во-вторых, потому что Вы не понимаете что наличие sql для in-process db это не плюс ни фига, а минус. Как минимум, в скорости, т.к. перед тем, как произвести какие-то действия с данными, запрос надо подготовить. В bdb всё наружу и подготовка и затрачиваемые на операции с данными ресурсы минимальны. В третьих... lua. Неплохой язык для своих задач, но здесь-то он зачем? Дань моде? Типа, у всех есть, а мы-то чёж как дурни без подарка? Ну ладно,барин, кобыла... Понимаю... =)))

А причины относительной не-популярности в том что «уже был redis» и «эти чертовы русские тут что-то замышляют».

Ну Ваша идея про «этих русских» тут вообще... Вы же мне не поверите что мой ник это не более чем троллинг? Ладно, я с этим как-то смирюсь. Но вот что делать тому же господину Кузнецову? Это который автор iproute2. Господину Сысоеву? Господину Олегу Бартунову? Это который автор полнотекстововго поиска в постгрес, по совместительству генеральный директор Постгрес профессиональный (Postgres Professional)? Впрочем, судя по фото и месту рождения в г. Элиста, он скорее всего калмык...

При чём здесь это всё вообще? Вы не думали над тем, что глядя на тарантул, у людей могут возникать (ИЧСХ, возникают!) ровно те же вопросы, что и у меня выше? Про sql & lua для key-value хранилищ. Все эти маркетинговые уверения про то, что «Оуууу! У нас тут большой проект!» вызывают не более чем кривую усмешку. Ввиду того, что мало кто понимает нахрена ломиться в открытые двери. Да, bdb уже есть, редис тоже и, если Вы наивно полагаете что до вас тут ни кого не стояло, то у меня для Вас плохие новости... =)))

OpenLDAP использовал Berkekey DB потому-что другого не было.

Вот тут злостное 4.2! И именно это и есть плохая для Вас новость Просто потому, что менеджер записей типа key-value под названием dbm, был написан Самим (sic!) Кеном Томпсоном аж в 1979г. С тех пор инкарнаций этой фигни «тулзени» было немало. Это и gdbm и ndbm (это вообще в стандарт POSIX 1003.1 занесло https://pubs.opengroup.org/onlinepubs/009695399/basedefs/ndbm.h.html). Т.е., понимаю что внезапно, но хранилища key-value были и без ваших соплей.

Однако, так же является фактом то, что у всех этих хранилищ была поганая производительность и не было ни репликаций, ни транзакций, ни фига. bdb в этом плане намного получше, да. Уж репликации там есть. Точно, я это гарантирую. =)))

postfix давно идёт тем-же путём.

И где про «этот же путь» сказано вот здесь, например? http://www.postfix.org/DB_README.html Ткните пальчиком? Или вот тут? http://www.postfixvirtual.net/postfixvirtual.html

Где мне увидеть фразу типа «Нет! Только не это! Только не bdb!!!11адын-адын»? По-моему, все просто используют данное решение, вне зависимости от Ваших фантазий о нём, я не прав? И не только в OpenLDAP и Postfix. Скорее всего, если Вы поищете у себя на винте, то bdb там будет. Сразу, с установленной системой, популярная штучка, знаете ли... =)))

20 лет доедать кактус - это как-раз кроваво-ынтерпрайзно ;)

Мне сострить насчёт того, что порох вообще 5000 назад (примерно) китайцы придумали и ни чего, как метательное ВВ вполне себе нормально убивает? Ну про С я даже и острить не буду... =)))

Всё-таки не понятно - нужна репликация или нет.

По-моему, я был прав насчёт дислексии... =)))

Но плотность ошибок там всё та же = не менее 1 на 100 кб исходников. Поэтому на 350К бинарника около 500-1000 багов.

Эвона как Вы затейливо про этих лохов педальных из Oracle, вообще ничего не понимающих в базах данных, которые не в состоянии заметить ошибок в количестве 1 на 100К исходников...

Я не оценивал данный продукт в этой части, по мне и так хорошо что сырцы не закрыли и я могу его использовать. Ну не тарантул же, в самом-то деле! =)))

Короче, DBSM ;)

Мдааа... По-моему, Вы явно не тем занимаетесь... Судя по Вашему комменту.

Скажите честно — продолжать будете или Вам и так хватит? =)))

Преклоняюсь перед Вашим опытом.

=)))

.

мимокрокодил

Вы, товарищ, как-то так выборочно процитировали предыдущий коментарий, что факт переписывания нахер хранилища в openldap с нуля потерялся.

Кто и когда его переписывал с нуля?

Вы, товарищ, как-то так выборочно процитировали предыдущий коментарий, что факт переписывания нахер хранилища в openldap с нуля потерялся.

Его кто-то переписывал? С нуля? Вы, часом, не поклонник тарантула? =))) Как там был bdb-backend, так и остаётся, наряду со всеми остальными-прочими, типа постгреса и мускуля.

UPD. Если бы Вы читали хоть что-то кроме своих исходников, например https://www.openldap.org/faq/data/cache/1073.html

То Вы с лёгкостью бы заметили что там явно сказано:

The Berkeley Database backend is the prefered database backend to use with OpenLDAP.

Ну, что ещё придумаете... товарисч? =)))

Его кто-то переписывал? С нуля?

А то же. lmdb называется.

Вы, часом, не поклонник тарантула? =)))

Нет, пауков не тыкал.

Как там был bdb-backend, так и остаётся, наряду со всеми остальными-прочими, типа постгреса и мускуля.
UPD. Если бы Вы читали хоть что-то кроме своих исходников, например https://www.openldap.org/faq/data/cache/1073.html
То Вы с лёгкостью бы заметили что там явно сказано:

The Berkeley Database backend is the prefered database backend to use with OpenLDAP.

Ну, что ещё придумаете... товарисч? =)))

Придумаю дать вам, товарищ, ссылку на настоящую документацию от openldap, вместо той фигни, которую вы читаете.

https://www.openldap.org/doc/admin24/backends.html

The mdb backend to slapd(8) is the recommended primary backend for a normal slapd database. It uses OpenLDAP's own Lightning Memory-Mapped Database (LMDB) library to store data and is intended to replace the Berkeley DB backends.

Скажите, а взять и создать хранилище key-value, прикрутив к нему lua (зачем?) и sql... Вам это ни чего не напоминает? Шутки про лунный модуль, блекджек и шлюх ещё в треде не было? По-моему, самое время... =)))

Все-таки это заносчивость и невежество, в духе «не читал, не понимаю, но осуждаю».

Ну я ещё могу понять sql, хотя он и вносит определённые задержки, т.к. его как минимум распарсить надобно, но... lua? Оно-то тут зачем? Впрочем, барин знает что с кобылой делать, наше дело хвост держать. =))) Не сомневаюсь что последний пассаж про барина и кобылу Вы по достоинству оцените. =)))

Могу порекомендовать углубиться в тему «почему в тарантуле так», ну и уже после рассуждать с чуть более умным видом.

Т.е., по данному пункту можно сделать несколько выводов. Во-первых, у Вас дислексия. Если бы её не было, Вы бы заметили что лично я про редис ни чего не писал. Как минимум потому, что вот редис уж точно это не для поставленной ТС задачи.

Редис является ширпотребный/общеизвестным key-value, с которым постоянно сравнивают тарантул. В том числе в духе «зачем тарантул, если есть редис». Поэтому упоминание редиски было ради тарантула, а НЕ в ответ на ваши тексты.

И на всякий - «дислексия» это про другое, т.е. не стоит употреблять «умные» слова не полностью владея их смыслом.

Во-вторых, потому что Вы не понимаете что наличие sql для in-process db это не плюс ни фига, а минус. Как минимум, в скорости, т.к. перед тем, как произвести какие-то действия с данными, запрос надо подготовить.

Если говорить о тарантуле, то RTFM (вовсе не обязательно использовать эту _дополнительную_ возможность).

Если вообще об SQL-интерфейсе, то prepare statement есть повсеместно в любой не-наивной БД с поддержкой SQL и не-наивном SQL/ODBC-драйвере. Соответственно, если нужны SQL-санки, то их придется немножко возить. Однако, лишние/неоправданные задержи будут только при неправильном/неумелом использовании API.

В bdb всё наружу и подготовка и затрачиваемые на операции с данными ресурсы минимальны.

В libmdbx/libfpta и LMDB аналогично, только overhead в ~100 раз меньше, а производительность выше. В частности поэтому LMDB в разы, а то и на порядки быстрее BDB (тузик - грелка, etc). http://www.lmdb.tech/bench/microbench/ https://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance

В RocksDB свои бонусы от LSM (но и затраты) и т.д. в добрых пяти десятках альтернатив BDB.

Вообще как-то странно обсуждать бабушку bdb, на поддержке которой oracle пытается заработать копеечку. Да, 20-25 лет назад bdb была на коне, но лучшее враг хорошего и лучшего понаделали очень много. Понятно что ынтерпрайзу проще платить за лицензии и поддержку, вместо того чтобы переписывать какой-то legacy код. Однако, советовать bdb сейчас для нового кода - мягко говоря очень сомнительно и странно.

Тем не менее, если вы поклонник BDB и желаете лично «укрепить позиции», то welcome = https://github.com/pmwkaa/ioarena/issues/11. Могу обещать ревью pull-request-а и пропушу по готовности.

В третьих... lua. Неплохой язык для своих задач, но здесь-то он зачем? Дань моде? Типа, у всех есть, а мы-то чёж как дурни без подарка? Ну ладно,барин, кобыла... Понимаю... =)))

Еще раз - всё-таки невежество, в духе «не читал, не понимаю, но осуждаю». Кстати, в redis тоже lua.

А причины относительной не-популярности в том что «уже был redis» и «эти чертовы русские тут что-то замышляют».
Ну Ваша идея про «этих русских» тут вообще... Вы же мне не поверите что мой ник это не более чем троллинг?

Ну про «русские что-то замышляют» - это шутка была.

> OpenLDAP использовал Berkekey DB потому-что другого не было.

Вот тут злостное 4.2! И именно это и есть плохая для Вас новость Просто потому, что менеджер записей типа key-value под названием dbm, был написан Самим (sic!) Кеном Томпсоном аж в 1979г. С тех пор инкарнаций этой фигни «тулзени» было немало. Это и gdbm и ndbm (это вообще в стандарт POSIX 1003.1 занесло https://pubs.opengroup.org/onlinepubs/009695399/basedefs/ndbm.h.html). Т.е., понимаю что внезапно, но хранилища key-value были и без ваших соплей.

Однако, так же является фактом то, что у всех этих хранилищ была поганая производительность и не было ни репликаций, ни транзакций, ни фига. bdb в этом плане намного получше, да. Уж репликации там есть. Точно, я это гарантирую. =)))

Тут мне пожалуй стоит уточнить - В OpenLDAP достаточно долго bdb-бэкенд использовался (и рекомендовался как основной), так как в нулевых не было _другого подходящего_. При этом верны ваши слова про плохие транзакции и прочие недостатки потомков dbm (но и делались эти «БД» для других сценариев, мягко говоря).

Однако, проблем с bdb было более чем достаточно и они существовали годами. Поэтому, получив «лицензионный» пинок от oracle, один из ведущих разработчиков OpenLDAP сделал усилие в виде LMDB. Это было примерно 10 лет назад, и теперь в master-ветке OpenLDAP уже нет BDB (выпилили месяц назад).

postfix давно идёт тем-же путём.

И где про «этот же путь» сказано вот здесь, например? http://www.postfix.org/DB_README.html Ткните пальчиком? Или вот тут? http://www.postfixvirtual.net/postfixvirtual.html

https://www.google.ru/search?q=postfix lmdb Кстати, Samba тоже.

Где мне увидеть фразу типа «Нет! Только не это! Только не bdb!!!11адын-адын»? По-моему, все просто используют данное решение, вне зависимости от Ваших фантазий о нём, я не прав? И не только в OpenLDAP и Postfix. Скорее всего, если Вы поищете у себя на винте, то bdb там будет. Сразу, с установленной системой, популярная штучка, знаете ли... =)))

bdb - это устаревшая встроенная key-value БД, которая еще используется в массе проектов. Причем «чуть менее чем во всех» этих проектах используется старые версии под Sleepycat License.

В новых проектах bdb-бабушку будет использовать либо незнакомый с современными альтернативами, либо не имеющий выбора по каким-то другим причинам.

> Всё-таки не понятно - нужна репликация или нет.

По-моему, я был прав насчёт дислексии... =)))

Репликацией по-прежнему называют слишком разные вещи. Включая путаницу между master-slave и multi-master, rfc4533, различными моделями консистенции и т.д. В этой связи совсем не ясно, что имел в виду топик-стартер под «репликацией», и нужна ли она ему на самом деле.

То что предлагает BDB - примерно специфический вариант костылей. Т.е. предоставляемый функционал можно назвать репликацией, но он мало кому подходит с учетом всех особенностей и ограничений. В реальности этим _очень_ мало кто пользуется, т.е. фактически только в legacy-проектах где в какой-то момент захотели прикрутить bdb-репликацию, прикрутили и не выбросили...

> Но плотность ошибок там всё та же = не менее 1 на 100 кб исходников. Поэтому на 350К бинарника около 500-1000 багов.
Эвона как Вы затейливо про этих лохов педальных из Oracle, вообще ничего не понимающих в базах данных, которые не в состоянии заметить ошибок в количестве 1 на 100К исходников...

Это была шутка, но только с долей шутки.

В oracle _очень_ хорошо понимают в маркетинге и продвижении. Один заход-тезис «бизнес-логика должна быть в хранимых процедурах на сервере» уже обеспечил им 20 лет безбедной жизни, и (думаю) принесет еще столько-же.

Но если говорить о количестве багов в коде и темпу их исправлений - то это общеизвестная проблема oracle, уже лет 15 как. В сети несложно найти страшилки от бывших работников и т.п.

Я не оценивал данный продукт в этой части, по мне и так хорошо что сырцы не закрыли и я могу его использовать. Ну не тарантул же, в самом-то деле! =)))

Думаю у вас еще есть шансы освоить.

Ну чтож, продолжим...

Уж коль скоро Вы так настойчиво просите.

А то же. lmdb называется.

Уверены? Или по обыкновению «не то сказали» или «Вас не так поняли»?

Придумаю дать вам, товарищ, ссылку на настоящую документацию от openldap, вместо той фигни, которую вы читаете.

Дали ссылочку? А ведь я Вас предупреждал... Ну теперь ловите в обрат.

Открываем https://linux.die.net/man/5/slapd-ldbm и читаем:

LDBM was the original database backend to slapd(8), and was supported up to OpenLDAP 2.3. It has been superseded by the more robust BDB and HDB backends.

Причина здесь в том, что ldbm это не реплицируемое хранилище key-value и, в случае, если нужна репликация, всем похрен насколько быстро она читает данные и насколько быстро пишет из-за отсутствия логов транзакций. В общем, она всем похрен. Окромя маргиналов.

Это было явно сказано в письме от Говарда Чоу, в тамошнем списке рассылки, в ответ на вопрос с какого хера в ldbm нет репликации, он заметил что для организации оной есть более чем до хера других продуктов (цитата не дословная, но смысл передан точно). Можно и пруфец найти, но мне лень... Сами нагуглите или мне придётся?

В общем, хорошая эта ваша штука ldbm, но у меня всё с bdb. Работает. И репликации всё таки есть на уровне БД, как вы там ни старайтесь «переписать с нуля» чего-то. Если делать нехер, то почему бы и нет? Я лично не против...

Уверены?

Уверен. Вы по ссылочке сходите, товарищ, а то вы какую-то херню про другую херню несёте.

Знаете... Я опасался насчёт Вашего диагноза...

Но нет. Вы его «блестяще» подтвердили.

Ещё раз — я ни чего не говорил про редис. Прочтите выделенную часть предыдущего предложения? Поняли что там написано? Ещё раз — я ни чего не говорил про редис.

Почему я ни чего не говорил про редис? Да потому, что у ТС явно оговорено — не шардинг данных, а их репликация. А memcached, redis, tarantool это ни хера не про репликацию, а про шардинг. Т.е., Вы, в своих стенах текста, откровенно не понимаете какую ярую антинаучную херню Вы несёте не по теме. В принципе не по теме.

Объясняю. Если бы мне бы нужен шардинг, то это очевидно что проект, где мне нужно держать данные, например, о коннектах. У меня есть готовые (проданные успешно) проекты, например, облачных (распределённых) виртуальной АТС, коммутатора (пофиг, L2/L3), файерволла. Или фронтенд для веб-аппликух, причём фронтенд размазан по нескольким серверам. Вот здесь да, редис во все поля. Здесь данные о «соединениях». Но это != репликация!

Более того. Почему здесь редис? Потому что ни кто не оговаривал необходимости держать 100% данных в RAM (привет, тарантул!). Потому что устройство может работать на ARM и там явно может получиться ситуация, когда всё плохо и памяти тупо не хватает. Чё, предлагаете взять этот ваш «большой проект» с SQL и LUA и позаниматься с ним сексом, в попытках заставить его хоть как-то работать в таких условиях? А, может, проще? Редис? Он-то уже работает, ЧСХ. И на ARM в том числе. Оверхед? Не, не слышл, hiredis и погнали.

Кстати, в redis тоже lua.

ЛОЛШТО?!? =)))

emerge -pvq redis
[ebuild   R   ] dev-db/redis-4.0.10  USE="jemalloc -luajit -tcmalloc -test" 

Насчёт того, что редис с lua, вывод команды приведён выше. В моём случае как захочешь, так и будет. Как там у Вас... ДА ктож вас там разберёт? =)))

Мне один бывший сотрудник мылору, помнится, вообще как-то рассказывал ужасное — что дескать bdb в принципе не поддерживает многопоточность. Могу назвать и имя-фамилию и чем (каким проектом) он там в мыле занимался. После этого... «взаимообогащающего общения» я зарёкся спорить с сотрудниками мылору. По всей видимости, там при приёме на работу мозг ампутируют. Боюсь я вас, в общем... =)))

Бггг... Дальше приведённой цитаты не читал. Уж простите. Там чёт про LMDB я у Вас в тексте краем глаза видел, применительно к OpenLDAP мой ответ анониму выше.

Насчёт того, что Вы пошутили... Понимаю и принимаю. Но беда в том, что я-то нет. Не шутил. =)))

Основная проблема «российского программирования» не в том, что «русских людей обижают». Основная проблема в том, что вместо использования и совершенствования существующих инструментов (да, это к числу ошибок в Oracle Embedded, о чём Вы столь глупо решили «пошутить») в России принято взять какую-то херню, широко распространённую в среде всех полутора ея разработчиков и начать онанировать над тушкой этой самой маргинальной херни. An mass, к сожалению, мы этим и занимаемся. Не решаем задачу так, «как люди делают, но лучше», а выдумываем какой-то с понтом дела высоконаучный гимор и потом удивляемся — а чё это ни кто не хочет присоединяться к грызению этого кактуса?

В общем, удачи. Мне хорошо с redis и bdb, желаю найти счастье с тарантулом. =)

Не уверен в осмысленности продолжения дальнейшей дискуссии, если честно.

Понимаю.

Сказать Вам больше нечего. И почему же я не удивлён, прямо и не знаю... =)))

UPD. Но Вы, главное, пилите ldbm... В конце-концов, когда коту делать нечего... Но Вы же не кот! Я в Вас и Ваш успех просто всеми фибрами души верю! =)))

Сказать Вам больше нечего.

А вы хотели, чтобы я на херню отвечал?

И почему же я не удивлён, прямо и не знаю... =)))

Значит вы таки намеренно ldbm и lmdb спутали?

А почему я её должен путать, мне интересно?

Я lmdb и не смотрел внимательно и не буду. Разок палочкой потыкал и хорош, дела надо делать. Просто потому что не вижу реальных преимуществ. Как не было в ldbm репликаций, так их и в lmdb нет. Смысл менять одно говно на другое?

Вот Вам ответ К. Чоу, радуйтесь — https://www.openldap.org/lists/openldap-technical/201507/msg00091.html

There are quite a few distributed data systems out there built on top of LMDB. Replication isn't really a subject area that's relevant to an embedded data store.

We are still planning to add incremental backup in LMDB 1.0. Other mechanisms could be built on top of that pretty easily.

Т.е., Вы хотите мне сказать что эти два сорта одного говна фатально различаются?

По-моему, Вы несёте херню. И да, Вам откомментировать нечего.

А почему я её должен путать, мне интересно?

А почему вы меня спрашиваете? Я вам говорю за lmdb, а вы мне отвечаете за что-то совсем другое, какой из этого можно сделать вывод? Разумеется, что вы их путаете, а почему вы должны это делать? Не знаю, может вас юристы из оракла за жопу взяли, а может вы просто укурены?

И да, Вам откомментировать нечего.

Я вам с первого коментария, что вы обходите стороной тот факт, что openldap ваш распрекрасный bdb решил выкинуть кхерам. А вы продолжаете вилять жопой, лжёте, пргаете с темы на тему, пытаясь увести разговор от этого простого факта.

Больше мне откомментировать нечего.

Цитата Чоу выше.

Скажите, в каких бекендах к базам данных, используемых в OpenLDAP, есть репликация? Постгрес, мускуль, bdb не называть.

Радоваться от того, что теперь очередное говно, от предыдущей инкарнации коего избавились в ранних версиях, теперь по трубам пролетает раз в 10-100 быстрее, я отказываюсь. От перестановки букв местами говно говном быть не перестаёт. Уж простите.

Делать репликацию на уровне самого протокола ldap (не важно — через syncrepl или через более старые механизмы), тоже не предлагать. Мы говорим о репликации на уровне бд, а не самого ldap.

Итак, Ваш ответ?

UPD.

Я вам с первого коментария, что вы обходите стороной тот факт, что openldap ваш распрекрасный bdb решил выкинуть кхерам.

Да Вы что?!? =))) И вот после этого пассажика Вы говорите что не несёте херню? «А мужики-то не знают...» =)))

Итак, Ваш ответ?

Вы опять пытаетесь увести разговор в сторону.

Да Вы что?!? =))) И вот после этого пассажика Вы говорите что не несёте херню? «А мужики-то не знают...» =)))

Вы, мужик, этого не знаете, потому что до сих пор не потрудились прочитать документацию по openldap. Вместо этого вы зачем-то читаете дерьмо типа die.net и FAQ 2013 года.

Нет. =)))

Я уже объяснил почему говно, это говно и ни что иное. Показал на ссылках. Попросил у Вас прямой ответ на прямой вопрос. Вы его дать отказываетесь, т.к. он Вам не выгоден. Понимаю. Но ни чего поделать не могу.

С верою в «светлое будущее» я спорить не буду. Не оскорбляю чувств, т.к. сам верующий. =)))

UPD. А к manу-то какие претензии? Нотариально заверенный скриншот мана на моём локалхосте надо? Там всё точно то же. Я проверял... =)))

Я уже объяснил почему говно, это говно и ни что иное.

Никому не интересно, почему говно — говно. Объясните почему openldap решил выкинуть конфетку и запилить говно с нуля, если конфетка — такая конфетка.

Знаете... Я опасался насчёт Вашего диагноза...
Но нет. Вы его «блестяще» подтвердили.

Вы невежественный хам, не понимающий объема своей некомпетенции.

Ещё раз — я ни чего не говорил про редис. Прочтите выделенную часть предыдущего предложения? Поняли что там написано? Ещё раз — я ни чего не говорил про редис.

Я дал пояснения почему упомянул редис, считаю их достаточными.

Почему я ни чего не говорил про редис? Да потому, что у ТС явно оговорено — не шардинг данных, а их репликация. А memcached, redis, tarantool это ни хера не про репликацию, а про шардинг. Т.е., Вы, в своих стенах текста, откровенно не понимаете какую ярую антинаучную херню Вы несёте не по теме. В принципе не по теме.

Объясняю. Если бы мне бы нужен шардинг, то это очевидно что проект, где мне нужно держать данные, например, о коннектах. У меня есть готовые (проданные успешно) проекты, например, облачных (распределённых) виртуальной АТС, коммутатора (пофиг, L2/L3), файерволла. Или фронтенд для веб-аппликух, причём фронтенд размазан по нескольким серверам. Вот здесь да, редис во все поля. Здесь данные о «соединениях». Но это != репликация!

https://www.tarantool.io/ru/doc/1.10/book/replication/ Еще раз, пожалуйста RTFM, а уже после делайте умный вид.

Более того. Почему здесь редис? Потому что ни кто не оговаривал необходимости держать 100% данных в RAM (привет, тарантул!). Потому что устройство может работать на ARM и там явно может получиться ситуация, когда всё плохо и памяти тупо не хватает.

https://www.google.ru/search?q=tarantool vityl Еще раз, пожалуйста RTFM, а уже после делайте умный вид.

Чё, предлагаете взять этот ваш «большой проект» с SQL и LUA и позаниматься с ним сексом, в попытках заставить его хоть как-то работать в таких условиях? А, может, проще? Редис? Он-то уже работает, ЧСХ. И на ARM в том числе. Оверхед? Не, не слышл, hiredis и погнали.

> Кстати, в redis тоже lua.
ЛОЛШТО?!? =)))

emerge -pvq redis
[ebuild R ] dev-db/redis-4.0.10 USE=«jemalloc -luajit -tcmalloc -test»
Насчёт того, что редис с lua, вывод команды приведён выше. В моём случае как захочешь, так и будет. Как там у Вас... ДА ктож вас там разберёт? =)))

https://www.google.ru/search?q=redis lua Еще раз, пожалуйста RTFM, а уже после делайте умный вид.

Мне один бывший сотрудник мылору, помнится, вообще как-то рассказывал ужасное — что дескать bdb в принципе не поддерживает многопоточность. Могу назвать и имя-фамилию и чем (каким проектом) он там в мыле занимался. После этого... «взаимообогащающего общения» я зарёкся спорить с сотрудниками мылору. По всей видимости, там при приёме на работу мозг ампутируют. Боюсь я вас, в общем... =)))

Читая вашу писанину я не уверен что вы могли что-ли правильно понять. BDB поддерживает многопоточность, но использовать её в большинстве случаев нет смысла. Из-за специфики реализации производительность растет далеко не линейно (т.е. CPU работает на обогрев), а из-за багов случается искажения данных. Смотрите баг-трекер.

Бггг... Дальше приведённой цитаты не читал. Уж простите. Там чёт про LMDB я у Вас в тексте краем глаза видел, применительно к OpenLDAP мой ответ анониму выше.

Еще раз: Вы - невежественный хам, не понимающий объема своей некомпетенции. И упорно не жалеющий смотреть на доказательства этой некомпетенции.

Основная проблема «российского программирования» не в том, что...

в том, что есть такие псевдо-специалисты как вы.

Не уверен в осмысленности продолжения дальнейшей дискуссии, если честно.

Аналогично.