Подскажите БД не сжирающую ОЗУ и флешку.

postgresql и mysql можно ограничить в апетитах по ОЗУ.
сначала подумал, что тебе сгодится sqlite,

и все перестает работать на 1 миллионе записей

но ты хочешь странного - чтоб быстро работало и памяти не давать.

Используй sqlite лучше.

Несколько странные трабования.
Хочешь много записей - mysql.
Хочешь мало памяти и скорости (и меньше миллиона записей) - sqlite.

P.S. Вообще хранить столько записей на embedded девайсе не лучшая идея, лучше подумать как это оптимизировать и куда-то вынести, иначе будет broken by design.

https://github.com/pmwkaa/engine.so

Может по старинке, взять sqlite и memcached и самому что-то мудрить с кешированием горячих данных в редис и скидыванием охдадевших в sqlite

Mail.ru Tarantool

SQLite, если уместитесь в ограничения:

Maximum Number Of Rows In A Table

The theoretical maximum number of rows in a table is 2**64 (18446744073709551616 or about 1.8e+19). This limit is unreachable since the maximum database size of 140 terabytes will be reached first. A 140 terabytes database can hold no more than approximately 1e+13 rows, and then only if there are no indices and if each row contains very little data.

Maximum Database Size

Every database consists of one or more «pages». Within a single database, every page is the same size, but different database can have page sizes that are powers of two between 512 and 65536, inclusive. The maximum size of a database file is 2147483646 pages. At the maximum page size of 65536 bytes, this translates into a maximum database size of approximately 1.4e+14 bytes (140 terabytes, or 128 tebibytes, or 140,000 gigabytes or 128,000 gibibytes).

This particular upper bound is untested since the developers do not have access to hardware capable of reaching this limit. However, tests do verify that SQLite behaves correctly and sanely when a database reaches the maximum file size of the underlying filesystem (which is usually much less than the maximum theoretical database size) and when a database is unable to grow due to disk space exhaustion.

доступно 128 Мб ОЗУ, вообще всего
все перестает работать на 1 миллионе записей

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

Ищется СУБД

https://rawgit.com/google/leveldb/master/doc/index.html

что бы можно было ограничить ей использование ОЗУ

  #include "leveldb/cache.h"

  leveldb::Options options;
  options.cache = leveldb::NewLRUCache(100 * 1048576);  // 100MB cache
  leveldb::DB* db;
  leveldb::DB::Open(options, name, &db);
  ... use the db ...
  delete db
  delete options.cache;

и что бы она учитывала, что база на медленной флешке.

Block size, Compression

All file operations (and other operating system calls) issued by the leveldb implementation are routed through a leveldb::Env object. Sophisticated clients may wish to provide their own Env implementation to get better control. For example, an application may introduce artificial delays in the file IO paths to limit the impact of leveldb on other activities in the system.

Подойдет любая СУБД

ldap

А надо полноценную СУБД? Просто у многих в основе KV с сортировкой по ключам и append-only логами.

Например leveldb (у него куча вариаций и альтернатив).

sqlite, никаких серваков не надо, всё зависит от тебя.

Файловая система с текстовыми файлами :)

SQLite

И как эффективно выковыривать нужное из текстовых файлов?))

Спасибо всем за отклики (мозговой штурм)!

То, что не похоже и предложили вместо mysql и sqlite буду еще гуглить.

Поясню про embedded - система изолирована от внешнего мира, IP канал GSM/GPRS, не IP канал GSM/CSD. В качестве флешки выступает SD-карта, от 1 до 8 Гб. Поэтому, с точки зрения заказчика, все его 5 миллионов записей с легкостью поместятся в пол гигабайта.

Комфортная скорость реакции при выборке, вставке, удалении - примерно одна секунда на 100 записей (и это НЕ постоянная скорость, а пиковая, такие порции редки). И mysql и sqlite, до миллиона записей, с лихвой укладываются.

sqlite попробовал, та же картина что и с mysql. Тот же предел порядка миллиона записей и ... база просто перепахалась и больше не открылась нигде (но это мелочи, может просто мои кривые руки).

mysql и sqlite - это конечно первое что попробовал в качестве решения.

НО - это все не специализированные хранилища для флешки (SD карта), и если бы не было затыка на 1 миллионе, они бы все-равно износили флешку очень быстро.

Может кто-то подскажет хранилище, которое оптимизировано для ведения базы именно на флешках?

ism, bookman900 - сейчас база так и наполняется, причем, разбил так, что каждый файл - это инфа за сутки.

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

Еще была идея «проиндексировать» записи «путем до файла, именем файла» в файловой системе и потом scandir... но это приводит к дублированию и такое количество в таких условиях ОЗУ уже не комфортно самой файловой системе - открытие файлов происходит минутами...

Итого выхода два - либо найти готовое, либо изобретать.

ограничить ей использование ОЗУ

учитывала, что база на медленной флешке

У хомяков как обычно следование взаимоисключающим параметрам.

база на медленной флешке

firebird уже советовали? :)

vertexua, за leveldb и ссылочки спасибо! Достойниый вариант.

Тоже спасибо! Ссылочек много, буду смотреть!

хранилище, которое оптимизировано для ведения базы именно на флешках?

RockDB (форк LevelDB, который уже здесь несколько раз упоминали) вроде позиционируется как такое хранилище

https://github.com/facebook/rocksdb

RocksDB: A Persistent Key-Value Store for Flash and RAM Storage

This code is a library that forms the core building block for a fast key value server, especially suited for storing data on flash drives.

Но как он себя поведет на 128М и на медленных флэшках непонятно, конечно

Да, это вопрос, ведь фейсбук его наверняка делал для серваков с немеренными объемами ОЗУ и SSD...

90% чтоб ваши нужды покрываются RRD чтобы писать/читать потоки данных (измерений, или что вы там ещё постоянно пишите) и немножко sqlite для всяких внутренних нужд типа конфигураций.

на флешке f2fs пользуй.

Ну есть такое понятие как сериализация, то есть упаковка массива в строку

Как вариант файловая система nilfs2 и база данных sqlite

Nilfs специально для флешек и очень быстра

Спасибо за советы!

Уже решил, что СУБД быть, теперь копаю различные БД по ссылкам, которые уже давали выше. Как что-то выберу, проверю, испытаю, обязательно отпишусь здесь, рано или поздно.

Построить индексы и записать их в бинарные файлы. Затем загружать индексы в оперативку на старте, не?

BDB еще глянь. Уникальные поля у записей есть, чтобы key-value использовать ?

Конечно же PostgreSQL!

Mail.ru Tarantool

Астрологи объявили неделю мылру? Сколько можно форсить эту срань?

А покажи как выглядит одна запись и какие ты собираешься делать запросы?

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

У меня, как и у всех, что-то подобное. Ключевые записи все, кроме value* и info. Привожу одну строчку, с полными именами полей и значениями, в реале всё оптимизировано по длине и пустые значения не сохраняются.

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

Выборка нужна, что бы не тащить весь файл, а только часть строк из него. По именам ключей сразу поймете, где выборка по диапазонам (дата и время), где строки (например, object1), а где перечисления (все остальное)).

< datetime1="2016-09-07-11-59-23-560093" datetime2="2016-09-07-11-59-25-000093" object1="dev1/pin4" object2="U" object3="" context1="" context2="" context3="" context4="" value1="711684.454456" value2="-1" value3="0" info="" />

СУБД ж так и делают. Не хочется за ними все это еще раз повторять.

Однако, все перечисленные движки (которые успел просмотреть) расчитаны на персоналки и сервера, а если не влазиют, то распределяются на несколько серваков.

А у меня исходные условия для СУБД другие, вот поэтому и задал вопрос в ЛОРе, ведь Linux очень часто в embedded применяется, вдруг кто-то решал сходную задачу. А пока получается, что все просто старались побырому прикрутить разное имеющееся :)

Скорее как шутка, но мало ли: глянь Harbour )))

SQLite, на крайняк Posgresql с тюнингом в докер контейнере (ограничить озу).

На кой сюда docker?

postgresql.conf не осилил, что ли?

Даже если и не шутка, я его под мой embedded аже и не соберу никогда из-за тысячи зависимостей )))

HOST - www.harbour-project.org[???]; PORT - 80
Valid name, no data record of requested type

Если у тебя timeseries, то глянь на akumuli.

https://harbour.github.io/

Зависит от задач, если у тебя пара таблиц, то запилить свою минибд на файлах с индексами на Си уйдет меньше, чем будешь выбирать из существующих БД и тестировать.

Вообще поищи на гитхабе может кто такое и делал даже.

Berkeley DB