Сравнение персистентных решений для устройства хранения данных в Python
Я запустил бы с существующего проекта, такого как поисковая система с открытым исходным кодом от Wikia.
[Мое понимание - то, что проект Поиска Wikia закончился. Однако я думаю, связываясь с существующим проектом с открытым исходным кодом, хороший способ упростить в обязательство этого размера.]
9 ответов
РСУБД.
Нет ничего более надежного, чем использование таблиц в хорошо известной РСУБД. На ум приходит Postgresql .
Это автоматически дает вам выбор на будущее, например, кластеризацию. Кроме того, у вас автоматически появляется множество инструментов для администрирования вашей базы данных, и вы можете использовать их из другого программного обеспечения, написанного практически на любом языке.
Это действительно быстро.
В пункте «Почувствуйте себя питоном» я мог бы добавить что вы можете использовать ORM. Строгое имя - sqlalchemy . Может быть, с помощью эликсира « extension ».
Используя sqlalchemy, вы можете предоставить своему пользователю / системному администратору возможность выбирать, какую базу данных он хочет использовать. Возможно, они уже установили MySql - нет проблем.
РСУБД по-прежнему являются лучшим выбором для хранения данных.
Возможно, вы захотите дать mongodb шанс - библиотека PyMongo работает со словарями и поддерживает большинство типов Python. Простота установки, высокая производительность + масштабируемость. MongoDB (и PyMongo) также используется в производстве некоторыми громкими именами.
Я работаю над таким проектом и использую SQLite .
SQLite хранит все в одном файле и является частью стандартной библиотеки Python . Следовательно, установка и настройка практически бесплатны (простота установки).
Вы можете легко управлять файлом базы данных с помощью небольших скриптов Python или с помощью различных инструментов. Существует также плагин Firefox (простота установки / простота использования).
Я считаю очень удобным использовать SQL для фильтрации / сортировки / управления / ... данных. Хотя, я не специалист по SQL. (простота использования)
Я не уверен, является ли SQLite самой быстрой системой БД для этой работы, и в ней отсутствуют некоторые функции, которые могут вам понадобиться, например, хранимые процедуры.
В любом случае, SQLite у меня работает.
Использование СУБД надежно масштабируемо и быстро.
Если вам нужно более масштабируемое решение и вам не нужны функции СУБД, вы можете использовать хранилище ключей и значений, такое как couchdb, которое имеет хороший python api.
У коллаборации NEMO (создание детектора космических нейтрино под водой) были почти те же проблемы, и они использовали mysql и postgresql без особых проблем.
если вам действительно нужно просто словарное хранилище, некоторые из новых хранилищ ключей / значений или столбцов, такие как Cassandra или MongoDB, могут обеспечить гораздо большую скорость, чем вы получили бы с реляционной базой данных. Конечно, если вы решите использовать СУБД, SQLAlchemy - это то, что вам нужно (отказ от ответственности: я являюсь его создателем), но ваш желаемый список функций, похоже, склоняется в направлении «Мне просто нужен словарь, похожий на Python»
Sqlite - он поставляется с питоном, быстрый, широко доступный и простой в обслуживании
Если вам нужны только простые (похожие на dict) механизмы доступа и эффективность обработки большого количества данных, то HDF5 может быть хорошим вариантом. Если вы собираетесь использовать numpy, то об этом действительно стоит подумать.
Это действительно зависит от того, что вы пытаетесь сделать. СУБД разработана для реляционных данных , поэтому, если ваши данные являются реляционными, используйте один из различных вариантов SQL. Но похоже, что ваши данные больше ориентированы на хранилище значений ключей с очень быстрыми случайными операциями GET. Если это так, сравните тесты различных хранилищ ключей, уделяя особое внимание скорости GET. Идеальное хранилище ключ-значение будет хранить или кэшировать запросы в памяти и иметь возможность обрабатывать множество запросов GET одновременно. Возможно, вы действительно захотите создать свой собственный набор тестов, чтобы вы могли эффективно сравнивать произвольные параллельные операции GET.
Зачем вам нужен кластер? Размер каждого значения очень велик? В противном случае вам не понадобится кластер для хранения миллиона записей. Но если вы храните большие объемы данных, это имеет значение, и вам может понадобиться что-то, что легко поддерживает ведомые устройства чтения и / или прозрачное разделение. Некоторые из хранилищ "ключ-значение" ориентированы на документы и / или оптимизированы для хранения больших значений. Redis технически более эффективен для хранения больших значений из-за накладных расходов на индексацию, необходимых для быстрых GET, но это не обязательно означает, что он медленнее. Фактически, дополнительное индексирование ускоряет поиск.
Вы единственный, кто действительно может ответить на этот вопрос, и я настоятельно рекомендую собрать собственный набор тестов для тестирования доступных вариантов с реальными сценариями использования. Данные, которые вы получите, дадут вам больше информации, чем что-либо еще.
Некоторые из хранилищ "ключ-значение" ориентированы на документы и / или оптимизированы для хранения больших значений. Redis технически более эффективен для хранения больших значений из-за накладных расходов на индексацию, необходимых для быстрых GET, но это не обязательно означает, что он медленнее. Фактически, дополнительная индексация ускоряет поиск.Вы единственный, кто действительно может ответить на этот вопрос, и я настоятельно рекомендую собрать собственный набор тестов для тестирования доступных вариантов с реальными сценариями использования. Данные, которые вы получите, дадут вам больше информации, чем что-либо еще.
Некоторые из хранилищ "ключ-значение" ориентированы на документы и / или оптимизированы для хранения больших значений. Redis технически более эффективен для хранения больших значений из-за накладных расходов на индексацию, необходимых для быстрых GET, но это не обязательно означает, что он медленнее. Фактически, дополнительное индексирование ускоряет поиск.Вы единственный, кто действительно может ответить на этот вопрос, и я настоятельно рекомендую собрать собственный набор тестов для тестирования доступных вариантов с реальными сценариями использования. Данные, которые вы получите, дадут вам больше информации, чем что-либо еще.
Redis технически более эффективен для хранения больших значений из-за накладных расходов на индексацию, необходимых для быстрых GET, но это не обязательно означает, что он медленнее. Фактически, дополнительное индексирование ускоряет поиск.Вы единственный, кто действительно может ответить на этот вопрос, и я настоятельно рекомендую собрать собственный набор тестов для тестирования доступных вариантов с реальными сценариями использования. Данные, которые вы получите, дадут вам больше информации, чем что-либо еще.
Redis технически более эффективен для хранения больших значений из-за накладных расходов на индексацию, необходимых для быстрых GET, но это не обязательно означает, что он медленнее. Фактически, дополнительное индексирование ускоряет поиск.Вы единственный, кто действительно может ответить на этот вопрос, и я настоятельно рекомендую собрать собственный набор тестов для тестирования доступных вариантов с реальными сценариями использования. Данные, которые вы получите, дадут вам больше информации, чем что-либо еще.