Недостаточно памяти и самая быстрая база данных запросов для проекта Python

Question

Я перевожу приложение GAE / Java на Python (не-GAE) из-за новой цены, поэтому я получаю небольшой сервер и хочу найти базу данных, которая соответствует следующим требованиям:

• Низкое использование памяти (или настраиваемое или предсказуемое)
• Возможность быстрого запроса простых данных / древовидных данных, идентифицированных по ключу (меня не волнует производительность при записи, и я предполагаю, что это будетимеют индексы)
• Привязки с совместимостью с Pypy 1.6 (или Python 2.7 как минимум)

Мои данные выглядят примерно так:

• Id: короткий ключстрока
• Заголовок
• Создатели: массив другой структуры данных, имеющий идентификатор - используемый в качестве ключа -, имя, адрес сайта и т. д.
• Теги: массивтегов.Каждый из них может иметь несколько родительских тегов, имя, идентификатор и т. Д.
• Лицензия: структура данных, которая описывает свою лицензию (CC, GPL, ... вы так говорите) с именем, связанным URL-адресом.и т. д.
• Время добавления: когда оно было добавлено на нашем сайте.
• Переводы: указатели на другие записи, которые являются переводами одного творения.

Мои запросыочень простыОбычные случаи:

• Фильтр по тегу, упорядоченный по времени добавления.
• Выберите несколько (нумерация страниц), упорядоченных по времени добавления.
• (Возможно, еще не сделано) фильтр по создателю.
• (не сделано, но запланировано) некоторые функции автозаполнения в формах, поэтому мне потребуется поиск, если некоторые поля содержат подстроку (запросы 'LIKE').

Объем данных не большой.Сейчас у меня около 50 МБ данных, но я планирую иметь огромный набор данных размером около 10 ГБ.

Кроме того, я хочу восстановить его с нуля, так что я открыт для любого варианта.Какая база данных, по вашему мнению, может соответствовать моим требованиям?

Редактировать: Я хочу сделать несколько тестов для разных вариантов и поделиться результатами.На данный момент я выбрал MongoDB, PostgreSQL, MySQL, Drizzle, Riak и Kyoto Cabinet.

Answer 1

Путь наименьшего сопротивления для переноса приложения ядра приложения, вероятно, будет использовать AppScale , который реализует основную часть API ядра приложения.В частности, вы можете использовать хранилище данных HyperTable , которое близко отражает хранилище данных Google App Engine.

Редактировать: хорошо, так что вы собираетесь провести редизайн.Я хотел бы остановиться на некоторых моментах, которые вы указали в своем вопросе.

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

Это в значительной степени противоположно тому, что вы хотите в базе данных;Вы хотите как можно больше своего набора данных в памяти ядра;Это может означать настройку самого набора данных для эффективного размещения или добавление memcached узлов, чтобы можно было распределить набор данных по нескольким хостам, чтобы у каждого хоста была достаточно малая часть набора данных, чтобы он уместился в ядре.

Чтобы довести эту мысль до конца, учтите, что чтение значения из оперативной памяти примерно в 1000 раз быстрее, чем чтение с диска;База данных, которая может удовлетворить каждый запрос от ядра, может в 10 раз увеличить нагрузку по сравнению с базой данных, которая должна посещать диск только для 1% своих запросов.

Я планирую иметь огромныенабор данных около 10 ГБ.

Я не думаю, что 10 ГБ можно назвать «огромным набором данных».Фактически, это то, что могло бы вписаться в оперативную память достаточно большого сервера баз данных;Вам не понадобится более одного узла memcached, гораздо меньше дополнительных узлов персистентности (типичные размеры дисков указаны в терабайтах, в 100 раз больше этого ожидаемого набора данных.

---

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

Answer 2

Я бы порекомендовал Postresql только потому, что он делает то, что вам нужно, может масштабироваться, быстр, довольно прост в работе и стабилен.

Это исключительно быстро в приведенных примерах запросов и может быть даже быстрее при запросах документов.