Сравнение постоянных решений хранения в python

Я начинаю новый научный проект, у которого много данных (миллионы записей), которые я хотел бы хранить в легко и быстродоступном формате. Я столкнулся с рядом различных возможных вариантов, но я не уверен, как их выбрать. Мои данные могут быть просто сохранены в виде словаря или, возможно, словарь словарей. Некоторые потенциальные соображения:

  • Скорость. Я не могу загружать все данные с диска каждый раз, когда я запускаю новый script, и я бы хотел как можно быстрее получить доступ к случайным записям.
  • Простота в использовании. Это питон. Хранилище должно выглядеть как python.
  • Стабильность/зрелость. Я хотел бы что-то, что в настоящее время поддерживается, хотя что-то, что хорошо работает, но все еще находится в разработке, будет в порядке.
  • Простота установки. Мой системный администратор должен иметь возможность запускать это в нашем кластере.

Мне не все равно, что размер хранилища, но это может быть важно, если на этом фронте действительно ужасно. Кроме того, если это имеет значение, я, скорее всего, буду создавать базу данных один раз, а затем только читать из нее.

Некоторые возможные варианты, с которыми я начал смотреть (см. этот пост):

Любые предложения, какие из них могут быть лучше для моих целей? Любые лучшие идеи? Некоторые из них имеют встроенный интерфейс; любые предложения о том, какой файловой системой файловой системы было бы лучше?

Ответ 1

A RDBMS.

Нет ничего более реалистичного, чем использование таблиц на хорошо известной СУБД. Postgresql приходит на ум.

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

Это очень быстро.

В точке "feel like python" я могу добавить, что вы можете использовать ORM. Сильное имя sqlalchemy. Возможно, с elixir "расширение".

Используя sqlalchemy, вы можете оставить своего пользователя /sysadmin выбрать, какой бэкэнд базы данных он хочет использовать. Возможно, они уже установили MySql - не проблема.

RDBMS по-прежнему являются лучшим выбором для хранения данных.

Ответ 2

Возможно, вы хотите дать mongodb выстрел - библиотека PyMongo работает со словарями и поддерживает большинство типов Python. Простота установки, очень эффективная и масштабируемая. MongoDB (и PyMongo) также используется

Ответ 3

Я работаю над таким проектом, и я использую SQLite.

SQLite хранит все в одном файле и входит в стандартную библиотеку Python. Следовательно, установка и настройка практически бесплатны (простота установки).

Вы можете легко управлять файлом базы данных с помощью небольших скриптов Python или с помощью различных инструментов. Существует также плагин Firefox (простота установки/простота использования).

Мне очень удобно использовать SQL для фильтрации/сортировки/обработки/... данных. Хотя, я не эксперт по SQL. (Легкость в использовании)

Я не уверен, что SQLite - это БД системы fastes для этой работы, и ей не хватает некоторых функций, которые могут вам понадобиться, например. хранимые процедуры.

В любом случае SQLite работает для меня.

Ответ 4

если вам действительно нужен словарь-подобный накопитель, некоторые из новых хранилищ ключей/значений или столбцов, таких как Cassandra или MongoDB, могут обеспечить гораздо большую скорость, чем вы могли бы получить с реляционной базой данных. Конечно, если вы решите пойти с РСУБД, SQLAlchemy - это способ пойти (отказ от ответственности: я его создатель), но ваш желаемый список функций, похоже, склоняется в направлении "Я просто хочу словарь, который похож на Python" - если вы не заинтересованы в реляционных запросах или сильной ACIDity, эти грани РСУБД, вероятно, будут казаться громоздкими.

Ответ 5

Sqlite - он поставляется с python, быстрый, широко доступный и простой в обслуживании

Ответ 6

Если вам нужны только простые механизмы доступа (dict like) и нужна эффективность для обработки большого количества данных, то HDF5 может быть хорошим вариант. Если вы собираетесь использовать numpy, то это действительно стоит рассмотреть.

Ответ 7

Go с RDBMS является надежным масштабируемым и быстрым.

Если вам требуется более масштабируемое решение и вам не нужны функции RDBMS, вы можете пойти с хранилищем значений ключа, например couchdb, который имеет хороший api python.

Ответ 8

Сотрудничество NEMO (построение космического нейтринного детектора под водой) было связано с такими же проблемами, и они использовали mysql и postgresql без серьезных проблем.

Ответ 9

Это действительно зависит от того, что вы пытаетесь сделать. RDBMS предназначена для реляционных данных, поэтому, если ваши данные являются реляционными, используйте один из различных вариантов SQL. Но похоже, что ваши данные более ориентированы на хранилище ключевых значений с очень быстрыми случайными операциями GET. Если это произойдет, сравните контрольные показатели различных хранилищ ключей, сосредоточив внимание на скорости GET. Идеальное хранилище ключей хранит или кэширует запросы в памяти и может обрабатывать многие запросы GET одновременно. Вы действительно можете создать свой собственный набор тестов, чтобы вы могли эффективно сравнивать случайные параллельные операции GET.

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

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