Быстрая только для чтения встроенная «база данных»?

Question

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

Iу меня была большая уверенность, что SQLite обеспечит производительность, но RDMBS кажется непригодным на фундаментальном уровне: объединения очень дороги из-за стоимости поиска по индексу, а в моем контексте только для чтения - ненужные накладные расходы, где объекты могут хранитьпрямые ссылки друг на друга в виде файловых смещений.Таким образом, поиск по индексу переключается для поиска файла.

Какие у меня варианты здесь?База данных действительно не описывает то, что я ищу.Я знаю о Neo4j, но не могу встроить Java в свое приложение.

TIA!

Редактировать, чтобы ответить на комментарии:

• Данныебудет иметь размер до 1 ГБ, и я использую PHP, поэтому хранение данных в памяти не является возможным вариантом.Я буду полагаться на буферный кеш ОС, чтобы избежать постоянного перехода на диск.
• Примером может служить таблица Product с 15 полями смешанного типа и запросом для перечисления продуктов с определенной маркой, объединяющихся в таблицу Category.
• Решением должен быть какой-то плоский файл.Мне интересно, существует ли уже какое-либо программное обеспечение, которое отвечает моим потребностям.

@ Марк Уилкинс:

Проблема производительности измеряется.По сути, в моей ситуации недопустимо заменять запрос 2 мс, связанный с вводом-выводом в Memcache, вызовом 5 мс, привязанным к ЦП, в SQLite ... Например, таблица категорий содержит 500 записей, содержащих родительские и дочерние категории.Следующий запрос занимает ~ 8 мс без дискового ввода-вывода: ВЫБЕРИТЕ 1 ИЗ категорий a ВНУТРЕННИЕ СОЕДИНЕНИЯ категории B на b.id = a.parent_id.Некоторые более простые запросы без объединения выполняются очень быстро.

Answer 1

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

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

Взгляните на следующее:

• PRAGMA Заявления: http://www.sqlite.org/pragma.html
• Пользовательские сборки SQLite: http://www.sqlite.org/custombuild.html
• Планировщик запросов SQLite: http://www.sqlite.org/optoverview.html
• Параметры компиляции SQLite: http://www.sqlite.org/compile.html

Все это, конечно, при условии, что вам нужна база данных.

Answer 2

Я не совсем понимаю ваши цели относительно типов запросов, которые вам нужны. Но часть о хранении смещений файлов для других данных кажется очень хрупким решением, которое сложно поддерживать и отлаживать. Там может быть какой-то инструмент, который поможет с этим, но я подозреваю, что вы в конечном итоге написали бы большую часть этого самостоятельно. Если кто-то еще придет позже, отладит и определит собственный формат файла, это будет больше работы.

Тем не менее, моя первая мысль состоит в том, чтобы задаться вопросом, оценивается ли описанная проблема производительности в этот момент или фактически измеряется. Вы запускали тесты с данными в реляционном формате, чтобы увидеть, насколько быстро это происходит? Это правда, что объединение почти всегда будет включать в себя больше операций чтения файлов (выполните бинарный поиск, как вы упомянули, затем получите информацию о связанной записи и затем найдите эту запись). Это может занять 4 или 5 или более дисковых операций ... сначала. Но в таблице категорий (из OP) он может в конечном итоге кэшироваться, если к нему обычно обращаются. Это полное предположение с моей стороны, но во многих ситуациях количество категорий относительно невелико. Если это так, то вся таблица категорий и ее индекс могут оставаться кэшированными в памяти ОС и, следовательно, приводить к очень быстрым соединениям.

Если производительность действительно является реальной проблемой, другой возможностью может быть денормализация данных . В примере категорий просто продублируйте значение / название категории и сохраните его с каждой записью продукта. В результате размер базы данных будет расти, но вы все равно можете использовать встроенную базу данных ( существует ряд возможностей ). Если все сделано разумно, оно все равно может поддерживаться на приемлемом уровне и обеспечивать возможность чтения всего объекта одним поиском / поиском и одним чтением.