Или вообще это уже не модно, и SQL решение странное и устаревшее?

Пацталом. Это я ответил на молодёжном языке.

Чего-то MariaDB с движком InnoDB, насколько понимаю, мало рабочее решение.

Не понял, откуда такое понимание. Без внешних ключей можно обходиться.

Что за ARM. Доступные СУБД зависят от операционной системы и дистрибутива и может быть даже от разновидности ARM. Надо ставить вопрос более конкретно.

Не понял, откуда такое понимание. Без внешних ключей можно обходиться.

И? Как это противоречит оригинальному высказыванию?

Чего-то MariaDB с движком InnoDB, насколько понимаю, мало рабочее решение.

А так вот, к примеру, рецепт https://layers.openembedded.org/layerindex/recipe/5974/

Там вообще невидно выбора движков. Видать в самом оригинальном сборщике MariaDB стоит блэклист на сборку InnoDB под ARM?

Или вообще это уже не модно, и SQL решение странное и устаревшее?

NoSQL имеет место быть, но оно модно сейчас в основном из-за того, что разработчики разучились в нормализацию, а планировать на шаг вперёд никогда и не умели.

Видать в самом оригинальном сборщике MariaDB стоит блэклист на сборку InnoDB под ARM?

У меня InnoDB работает на raspberry pi 2 из стандартных реп убунту. Еще есть sqlite

Arm или arm64?

arm7hf

Небольшая СУБД на ARM

sqlite

А точно. В дебиан под arm есть и дефолтом стоит...

Смотря на чём писать.

Однако, я бы проголосовал за Oracle Embedded https://www.oracle.com/database/berkeley-db/, если нужно создавать локальную БД для приложения(-ий). Быструю и без SQL.

Либо SQLite.

А какую задачу ты решаешь? Что ты собираешься хранить и нужно ли embedded решение?

1) ARM-ов много разных. 2) То, что в Yocto по дефолту не собирают InnoDB, не значит, что оно на ARM не работает. Может они ради экономии места так сделали 3) Никто не мешает тебе самостоятельно скомпилировать любую СУБД под твой девайс

/berkeley-db/

Слышал, что у bdb проблем решать больше, чем написать lmdb.

Тут где-то...

Мы общались тут где-то с одним клоуном-регистрантом. Который автор этой lmdb. Он ни как не мог ответить на вопрос есть ли репликация в его поделии, например. По крайней мере, я ответа не получил.

В bdb есть, пользуюсь. Транзакции есть. Вполне зрелый продукт. А единственная проблема с bdb заключается в том, что погроммисты не осиливают прочесть что-нибудь про in-memory database in berkeley db. Т.е., база, хранимая в памяти. Правда, у ТС навряд ли так будет стоять задача, т.к. ARM это ARM и там наврядли найдётся гектар-другой лишний. Но факт остаётся фактом. ;) В bdb можно создавать и использовать весьма быстрые базы. Свойство репликации сохраняется и в этом случае.

С другой стороны, кстати, bdb умеет ещё и шифрованные базы. Как именно embedded db (именно bd, а не «менеджер записей») вполне-вполне. Использую сам, отказываться не планирую.

UPD. Ну и в качестве апелляции к авторитету (понимаю что не хорошо, но всё же) — Oracle это как ни крутите, а Oracle. И в массе продуктов как-то незаметны «проблемы», якобы существующие в bdb.

автор этой lmdb

Автор lmdb Howard Chu (не знаю как это правильно транслитерировать на русский, Говард Чу?), вряд ли он зарегистрирован на лоре.

Лоровский erthink - автор своего форка lmdb с какими-то дополнительными фичами

Я тупой: что такое внешние ключи, чуть подробнее. Так то я за SQLite как и другие, но прежде чем советовать любимый эскулайтик лучше уточнить: что подразумевается под внешними ключами?

Или не так: какой профит должны привнести внешние ключи, может я так пойму их назначение.

Так-то народ и PostgreSQL под малинку собирал, хотя автор заметки по ссылке признаёт, что это экзотика.

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

Или вообще это уже не модно, и SQL решение странное и устаревшее?

Толсто.

Foreign keys. Стандартный в мире реляционных СУБД механизм обеспечения целостности данных, связь между несколькими таблицами.

В SQLite они, кстати, есть. :)

firebird ?

Foreign keys. В SQLite они, кстати, есть. :)

Да??? ТС: shut up and take SQLite /thread )))

единственная проблема с bdb

Кстати, минут 10 тому наткнулся на ещё одну единственнаую проблему — если процесс неудачно прибить, оно больше не стартует, нужно бубном прочищать.

наткнулся на ещё одну единственнаую проблему

Еще несколько лет назад обсуждали некоторую глючноватость BDB: Berkeley DB всегда была глючной?

Подозреваю что Moisha_Liberman или не очень-то ее использует, или обладает какими-то тайными знаниями кроме репликации и in-memory database in berkeley db.

Мы общались тут где-то с одним клоуном-регистрантом. Который автор этой lmdb. Он ни как не мог ответить на вопрос есть ли репликация в его поделии, например. По крайней мере, я ответа не получил.

Вы получили все ответы, но желали (или смогли) их понять.

Лирический off-topic: Еще раз повторю что вы = малограмотный хам, упрямо игнорирующий советы RTFM. Кроме этого, вы лжете чтобы выглядеть «умнее».

Автор LMDB не я, а Говард Чу (Howard Chu). Мое же «поделие» получилось в процессе починки падений и глюков OpenLDAP для Мегафона, что в итоге привело к появлению ReOpenLDAP и MDBX.

В LMDB и MDBX нет репликации, что явно и сказу было озвучено. Причем есть достаточно веских причин не тащить сюда репликацию, ибо будет гибрид ужа с ужом наподобие BDB. При этом стоит отметить что работающая мульти-мастер репликация (синхронизация содержимого) по RFC-4533 есть в ReOpenLDAP.

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

При этом BDB исторически предлагает плохой (уродливый) баланс между возможностями, удобством API, производительностью, стабильностью и durability, потреблением ресурсов. Т.е. для любой комбинации этих ключевых параметров можно подобрать превосходящее решение.

Поэтому для OpenLDAP был сделан движок LMDB, а BDB уже выпилили. Примерно тоже самое произошло/происходит в Postfix, Samba и т.д.

Ну а использовать «репликацию» предлагаемую в BDB - это как строгать свои пальцы, чтобы засунуть в розетку.

Oracle это как ни крутите…

Везде Ж..па, так уж выходит ;)

Подозреваю что Moisha_Liberman или не очень-то ее использует, или обладает какими-то тайными знаниями кроме репликации и in-memory database in berkeley db.

Думаю он упоротый, как минимум частично.

Куда-то впилил BDB не разобравшись с альтернативами и плюсами/минусами, а теперь пытается убедить себя и всех что это было правильно.

Зачем задавать такие вопросы при живом-то sqlite3?

Всё верно.

Как уже писал libmdbx и ReOpenLDAP получились в процессе починки LDAP-а для Мегафона (см 11-ю страницу в «тезисах» докладов с Альтовой конференции в Калуге).

Превосходства MDBX над LMDB перечислены в README.

Из минусов - у меня поддержка только Linux и Windows, и на mustdie медленнее из-за файловых блокировок (зато надежнее).

Но LMDB и MDBX тут все-таки off-topic, так это «голое» key-value storage без SQL и каких-либо внешних ключей.

Тем не менее, если дошли до MDBX/LMDB, то стоит упомянуть:

• Несколько лет назад Говард Чу сделал (и забросил) форк SQLite работающий поверх LMDB.

• libfpta предлагает таблицы с несколькими видами индексов поверх MDBX. Там нет SQL, а только C/C++. При этом «внешние» ключи несложно реализовать прослойкой.

nosql удобнее для разработки и прототипирования, а если мне мюджет под DBA выделят я не против на чем угодно писать, но только если

Тебе в том треде объяснили, что bdb --дерьмо и с него все валят. Я тебе позитивно поражаюсь, тебя, трепло, в каждом треде в твою ложь носом тычут, а тебе как с гуся вода.

Всё просто.

Bdb нельзя так просто взять и... короче, готовить её правильно надо. Тайного тут ни чего нет, за столько-то лет даже книги уже по ней были написаны.

Насчёт глючноватости прочёл ссылку. Ну что я могу сказать... иногда жизнь, наверное, боль.

Всё верно.

если процесс неудачно прибить, оно больше не стартует, нужно бубном прочищать.

Процесс так просто ронять не стоит. Лучше корректно за собой всё закрывать и рестартовать заново. Иначе, что по всей видимости, в Вашем случае и происходит, лог транзакций остаётся подвисшим. В этом случае либо используйте db_recvery (внешний утиль), либо открывайте бд с DB_ENV->open(), выставив флаг DB_RECOVER || DB_RECOVER_FATAL. Старт приложения может малость подзатянуться в этом случае, но лог транзакций распинается.

Да! Точно! Простите, был неправ.

Автор lmdb Howard Chu (не знаю как это правильно транслитерировать на русский, Говард Чу?), вряд ли он зарегистрирован на лоре.

Вы абсолютно правы.

Просто, в том общении со вторым названным Вами персонажем, я всё пытался выяснить у него почему же авторы этих key-value storage так любят называть свои поделия database. Собственно, этих поделий сейчас примерно как говна за баней (http://embedded-databases.com/).

Чтобы поставить тут точку, напомню об одном сравнении на хабре. Вот об этом — https://habr.com/ru/post/243451/, где автор опроса вспомнил о lmdb только после того, как ему напомнили об этом. Где-то в районе третьего коммента.

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

Второй персонаж там включил режим «кисо обиделось, афтара может забидеть каждый», так что я его первым делом и вспомнил когда речь зашла об lmdb.

Просто, в том общении со вторым названным Вами персонажем, я всё пытался выяснить у него почему же авторы этих key-value storage так любят называть свои поделия database. Собственно, этих поделий сейчас примерно как говна за баней (http://embedded-databases.com/).

Вы были посланы в RTFM (кажется сюда) для ознакомления с разницей между терминами «база данных» (aka database) и СУБД (aka DMBS).

Поэтому таки вынужден высказаться явно: Moisha_Liberman = פּאָצעװאַטע лгун.

Чтобы поставить тут точку, напомню об одном сравнении на хабре. Вот об этом — https://habr.com/ru/post/243451/, где автор опроса вспомнил о lmdb только после того, как ему напомнили об этом. Где-то в районе третьего коммента.

Ну это никакое не сравнение, а (мягко говоря) странный опрос о «популярности» key-value среди читателей хабра. Рома Левентов намекал на его несерьезность, назвав «Битвой», но ирония осталось незамеченной.

Там смешано столько теплого, мягкого и зеленого, что больно смотреть. А вывод только один - половина проголосовавших умеет Redis и мечтает чтобы он был «резиновый».

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

Феноменально безграмотный и наивный апломб.

Самое адекватное сравнение на хабре (пожалуй) сделано в статье «Key-value для хранения метаданных в СХД. Тестируем встраиваемые базы». Там хотя-бы сравниваются более-менее сравнимые вещи в рамках какой-то задачи, в том числе есть релевантный комментарий ко второй части. Однако и это тестирование с результатами заставляет ему НЕ верить.

Второй персонаж там включил режим «кисо обиделось, афтара может забидеть каждый», так что я его первым делом и вспомнил когда речь зашла об lmdb.

Вынужден повторить: Moisha_Liberman = פּאָצעװאַטע лгун.

Процесс так просто ронять не стоит

Ну да, именно это и есть «проблема». Нынче столько развелось компутеров*процессов, что не получается думать о том, какие из них «не стоит ронять».

Не знаю.

Я стараюсь гасить хосты корректно. Тогда демоны, использующие эту базу тоже гасятся корректно, проблем не возникает.

Я стараюсь

Вот! А должны были стараться программисты. Ибо программа пишется 1 раз, а роняется много.

Мы общались тут где-то с одним клоуном-регистрантом.

Этого олень https://habr.com/ru/post/459862/#comment_20414205 что-ли?

Зачем мне это читать?

Я выше привёл целый список сходных и зачем-то написанных решений. Их всех что ли читать? Мне нужен рабочий инструмент и он у меня есть. Плюс, я его умею готовить.

В смысле?

Вот! А должны были стараться программисты. Ибо программа пишется 1 раз, а роняется много.

Я и есть тот самый программист (один из), который в курсе что если демон останавливается например при перезагрузке сервера, то лучше бы закрыть используемые ресурсы. Если какой-то «приклад» останавливается или выходит по exit(), то наверное должна быть ф-я, которая зарегистрирована через atexit() и которая закроет ресурсы. Ну и при запуске программы я умею правильно открывать базу (см. выше).

Презагружать сервак нажимая на клавишу питания это плохая практика. Иначе как умудриться всё поронять, я себе и не представляю даже.

Я и есть тот самый программист (один из), который ...

... умеет правильно закрывать ресурсы за 13 микросекунд до нажатия пользователем reset или включения оом-килера, выхода из строя источников питания, осевой паники или зависания по независящим причинами и непредусмотренных дедлоков в коде, использующем мои либы. Рад за человечество.