Что такое «лучшая» база данных для встроенных?

Question

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

Встроенное устройство основано на процессоре ARM 9, работающем на частоте 220 МГц.

Должна быть база данных из 50 тыс. Записей (может увеличиться до 250 тыс.), Каждая с 1 тыс. Данных (максимум 8 заявок). Это приблизительное - я могу попытаться получить более точные цифры, если это необходимо.

Они в настоящее время С помощью SQLite 2 и планирует перейти к SqlLite 3.

Не запуская пламени войны - я полный d/б новичку просто обратиться за консультацией - это то, что «лучший» решение? Я понимаю, что это может быть «как долго это кусок струны?» вопрос, но любые указатели будут очень приветствоваться. Я не прочь сделать много чтения & исследований, но просто надеялся, что вы можете меня отпустить на летящий старт. Благодарю.

p.s Опять же, полная перезапись может даже не встать со встроенной Linux, а переключиться на eCos, не беспокойтесь слишком много о однократном преобразовании между форматами d/b. О, и доступ должен быть нечастым, не чаще одного раза в несколько секунд.

---

редактировать: хорошо, кажется, что они имеют 30k записи (может достигать 100k или более) только 5 или 6 полей каждого, но, по крайней мере, 3 из них может быть ключ поиска для записи. Они ориентируются на «отсутствие d/b вообще, поскольку данные такие простые», но мне кажется, что с несколькими ключами мы не могли использовать причудливые вещи, такие как поиск типа quicksort() (рекурсивный, двоичный поиск). Любые мысли о «нет d/b», просто структуры данных?

Btw, один ключ 800k - не знаю, насколько хорошо SqlLite ручки, что (возможно, с «нет d/б» у меня хэш что 800k к чему-то меньшего?)

Answer 1

Также SQLite - это база данных, выбранная практически всеми мобильными операционными системами. Android, Iphone OS и Symbian поставляются с SQLite, что заставляет меня думать, что рабочая сила была потрачена на то, чтобы оптимизировать ее для процессора на этих телефонах (почти всегда ARM).

Answer 2

Я бы придерживаться SQLite, это широко поддерживаются и довольно богаты функциями.

Answer 3

я не знаком с системой вставлять, но и использовать iphone ARM9 и sqlite в БД

Answer 4

• Firebird (ранее Interbase) утверждает, что хорошо работать внедренный.

• HypersonicQL (HQL) является небольшим и быстрым, а также утверждает, что он подходит для использования внутри помещений.

Увы, у меня нет личного опыта для резервного копирования любой заявки.

Answer 5

Я также предлагаю sqlite3. Используется многими известными приложениями.

Answer 6

SQLite, вероятно, довольно безопасная ставка. Однако, если производительность действительно важна для вашего приложения, и вам не нужна реляционная база данных, я бы предложил вам взглянуть на Berkeley DB link text. Однако Berkeley DB не является реляционной базой данных. Другими словами, если ваши данные сгруппированы в разные таблицы, и вам постоянно нужно запрашивать наборы результатов, которые требуют связывания данных из более чем одной таблицы, вам, вероятно, нужна реляционная база данных.Berkeley DB лучше подходит для чего-то вроде поисковых таблиц (т. Е. Данные организованы в несколько таблиц, и вам не нужно запрашивать данные из более чем одного из них, чтобы создать нужные вам наборы результатов). Berkeley DB работает очень быстро, но для этого вам потребуется больше работы, чтобы максимально использовать его.

Answer 7

Информационный бюллетень Embedded.com 01-11-10 делает хорошую работу по освещению этой темы. Информационный бюллетень можно найти на сайте Embedded.com: Embedded.com Tech Focus Newsletter (1-11-10): Embedding Databases.

Answer 8

если вы хотите альтернативу, то berkeleydb стоит посмотреть. он раньше принадлежал программному обеспечению sleepycat, но теперь доступен от oracle. это базовый движок базы данных; является прямо программируемым (а не sql) интерфейсом. он используется как часть основного движка во многих основных базах данных и как база данных во многих встроенных устройствах - он был особенно популярен для управления таблицами маршрутизации в маршрутизаторах. В наши дни он имеет тенденцию упускать из виду все более модные настройки, но я нашел, что он приличный, прочный и для чисел, о которых вы говорите, может быть молниеносно.

Answer 9

SQLite в порядке, но не планируете использовать, если вы планируете вставлять, обновлять и удалять данные, которые включают в себя более 6 миллионных строк (все одновременно или любую часть). Дело в том, что ключевое слово VACCUM должно выполняться каждый раз, а затем, и это становится очень серьезным узким местом для производительности, даже когда оно автоматическое.