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

Если вам нужно что-то действительно масштабируемое, я бы не стал выбирать плоский или XML-файл. По мере роста ваших данных это может снизить вашу производительность.
Если у вас будет много данных на каком-то этапе, я бы все равно выбрал базу данных - я бы взглянул на что-то вроде SQLIte с очень простой схемой, которая соответствует вашим потребностям.
Всегда есть SQLite, база данных, которая хранится в файле. SQLite уже имеет встроенный параллелизм, поэтому вам не нужно беспокоиться о таких вещах, как блокировка файлов, и это очень быстро для чтения.
Однако, если вы вносите много изменений в базу данных, лучше всего сделать их все сразу внутри сделка. При этом изменения будут записаны в файл только один раз, а не каждый раз, когда будет выдан запрос на изменение. Это значительно увеличивает скорость внесения нескольких изменений.
Когда выдается запрос на изменение, вне зависимости от того, находится ли он внутри транзакции или нет, вся база данных блокируется до тех пор, пока этот запрос не завершится. Это означает, что чрезвычайно большие транзакции могут отрицательно повлиять на производительность других процессов, потому что они должны дождаться завершения транзакции, прежде чем они смогут получить доступ к базе данных. На практике я не обнаружил, что это так заметно, но всегда полезно попытаться минимизировать количество запросов на изменение базы данных, которые вы отправляете.
SQLite фантастичен и легко интегрируется в приложение. Лучше всего то, что для его использования не требуется установка на стороне клиента, все это встроено в приложение.
Однако у него есть проблемы с параллелизмом.
Я действительно не уверен, что вы должен, но рассматривали ли вы просто сохранение информации в XML-документе, если это действительно так? А если это не вы считали SQLite?
Если вам нужна масштабируемость, то РСУБД - ваш лучший выбор. На самом базовом уровне вы можете сериализовать структуры данных в файлы, однако тогда вам придется учитывать проблемы блокировки файлов, которые ограничивают параллелизм.
SQLite - это механизм базы данных на основе файлов SQL, который может работать без постоянного демона базы данных (например, в PHP он работает как расширение), однако он также имеет проблемы с параллелизмом (прочтите ответы на этот вопрос, которые могут помочь вам решить, стоит ли SQLite подходит именно вам).
Если у вас нет действительно веской причины не использовать настоящую DRBMS, я бы посоветовал вам придерживаться MySQL или других «полноценных» движков.
Если вы пишете java-программу, которая хочет встроенную базу данных, посмотрите на hsqldb, поскольку он написан на java и работает намного лучше, чем sqlite, если он вызывается из java-программ.
Если вы пишете Java, то есть реализации базы данных Java (Джаред упоминает hsqldb, есть и другие), которые вы можете напрямую включить.
SQLite подходит для статического включения, однако вы также можете включить MySQL в свое приложение, если используете совместимый язык, такой как C.
Я думаю, вы также оценили бы наличие SQL. XML-файлы просто больше не сокращают, может быть, пару лет назад, когда писали программное обеспечение для КПК, но даже iPhone и Android теперь включают SQLite.
hsqldb в режиме в памяти даст вам гораздо лучшую производительность, чем базы данных на основе плоских файлов. Его тоже довольно легко использовать. И если таблица становится слишком большой, есть возможность кэшировать ее также на диске. Посмотрите это сравнение производительности:

(source: hsqldb.org)
если вам нужен «постоянный кеш» и вы уже используете memcached, отметьте memcachedb. это постоянная хеш-таблица с использованием протокола memcached, нет необходимости в новом клиенте (но в новом демоне)
Для пар ключ = значение вы можете использовать формат файла INI с простыми процедурами загрузки и сохранения, чтобы загрузить и сохранить в хеш-таблице в памяти.
Позже это можно масштабировать до любого уровня, просто изменив процедуры загрузки и сохранения для работы с db.
Вы можете попробовать CounchDB, это очень гибкая документно-ориентированная база данных, которая не заставляет вас заранее определять схему. Он был написан на Erlang и благодаря этому считается очень масштабируемым решением. Его можно легко запросить через интерфейс REST.
Я недавно спросил аналогичный вопрос. Вот несколько вариантов:
ESE отлично подходит для больших объемов данных, не обязательно в качестве кеша. Он отлично работает с AD, Exchange, Wins, FRS и другими технологиями.
Вердикт: SQLite! :)