Встроенный SQLite / Firebird для числовых данных
У меня есть эксперимент по потоковой передаче 1 Мб / с числовых данных, которые необходимо сохранить для последующей обработки. Кажется, что запись непосредственно в базу данных так же легко, как и в файл CSV, и тогда у меня будет возможность легко извлекать подмножества или диапазоны.
У меня есть опыт работы с sqlite2 (когда в нем были только текстовые поля), и он казался почти таким же быстрым, как необработанный доступ к диску. Есть ли какие-либо мнения о лучших текущих СУБД для этого приложения?
Извините - нужно было добавить, что это C++ изначально для Windows, но кроссплатформенность хороша. В идеале двоичный формат БД должен быть кроссплатформенным.
Ответы 5
Зависит от того, какой язык вы используете. Если это C / C++, TCL или PHP, SQLite по-прежнему остается одним из лучших в сценарии с одним писателем. Если вам не нужен доступ к SQL, библиотека в стиле Berkeley DB может быть немного быстрее, например Sleepycat или gdbm. С несколькими авторами вы можете рассмотреть отдельное клиент-серверное решение, но это не похоже на то, что вам это нужно. Если вы используете Java, hdqldb или derby (поставляемые с JVM Sun под брендом «JavaDB») кажутся наиболее предпочтительными решениями.
Если все, что вам нужно, это хранить числа и иметь возможность легко ранжировать запросы, вы можете просто взять любую стандартную древовидную структуру данных, доступную в STL, и сериализовать ее на диск. Это может укусить вас в кроссплатформенной среде, особенно если вы пытаетесь перейти на кросс-архитектуру.
Что касается более гибких / удобных для людей решений, sqlite3 широко используется, надежен, стабилен и очень приятен во всех отношениях.
BerkeleyDB имеет ряд хороших функций, для которых его можно было бы использовать, но ни одна из них не применима в этом сценарии, imho.
Я бы посоветовал перейти на sqlite3, если вы принимаете лицензионное соглашение.
-D
Если вам нужно только читать / записывать данные без каких-либо проверок или манипуляций, выполняемых в базе данных, тогда оба должны делать это нормально. Файл базы данных Firebird может быть скопирован, если система имеет тот же порядок байтов (т.е. вы не можете копировать файл между системами с процессорами Intel и PPC, но Intel-Intel в порядке).
Однако, если вам нужно когда-либо что-то делать с данными, помимо простого чтения / записи, тогда используйте Firebird, поскольку это полноценный SQL-сервер со всеми «корпоративными» функциями, такими как триггеры, представления, хранимые процедуры, временные таблицы и т. д. и Т. Д.
Кстати, если вы решите попробовать Firebird, я настоятельно рекомендую вам использовать библиотеку IBPP для доступа к ней. Это очень тонкая оболочка C++ вокруг C API Firebird. У меня около 10 классов, которые инкапсулируют все, и им очень легко пользоваться.
Я подозреваю, что ни одна из баз данных не позволит вам записывать данные с такой высокой скоростью. Вы можете убедиться в этом сами, чтобы убедиться. По моему опыту - SQLite не удалось ВСТАВИТЬ более 1000 строк в секунду для очень простой таблицы с одним целочисленным первичным ключом.
В случае проблем с производительностью - я бы использовал формат CSV для записи файлов, а позже загружал бы их данные в базу данных (SQLite или Firebird) для дальнейшей обработки.
Спасибо, высокоскоростное приложение так и не было реализовано, поэтому у меня не было возможности запустить его.
Вы уверены, что использовали SQLite с соответствующими настройками? См. sqlite.org/faq.html#q19
Ну, флаг синхронизации я не отключал. Возможно, с выключенным флагом производительность лучше (однако - вы рискуете повредить базу данных в случае сбоя питания).
Вы также можете рассмотреть формат файла числовых данных, который специально предназначен для хранения этих типов больших наборов данных. Например:
- HDF - наиболее распространенный и хорошо поддерживаемый на многих языках с бесплатными библиотеками. Я очень рекомендую это.
- CDF - аналогичный формат, используемый НАСА (но пригодный для использования кем угодно).
- NetCDF - еще один аналогичный формат (последняя версия - это урезанный HDF5).
Эта ссылка содержит некоторую информацию о различиях между указанными выше типами наборов данных: http://nssdc.gsfc.nasa.gov/cdf/html/FAQ.html
Это то, что я делаю сейчас, STL-> xml, но, похоже, много накладных расходов при очень небольшом выигрыше. БД дает мне возможность сделать что-то более умное в будущем без необходимости писать дополнительный код.