Какая база данных (ы) следует использовать для преимущественной записи один раз/Чтение Многие операции?

Я создаю приложение, которое должно запрашивать много данных, которые пишутся один раз и больше не меняются. Должен ли я использовать MySQL для этого или использовать что-то вроде SimpleDB или BigTable? (Мне нужно писать раз, много раз читайте)Какая база данных (ы) следует использовать для преимущественной записи один раз/Чтение Многие операции?

Спасибо.

Редактировать: Я хочу использовать Heroku, большой для меня более 5 МБ. «Тысячи строк» занимают более 5 МБ. Вот почему мне интересно, следует ли использовать CouchDB, SimpleDB или MongoDB, чтобы не платить 15 долларов, которые Героку взимает. Предложения по преодолению этого? Спасибо всем за комментарии!

источник

2010-08-17 donald

Хотите присоединиться? Вы хотите получать данные по атрибутам, отличным от UID? Насколько важна производительность? Под «множеством данных» вы имеете в виду большие множества из нескольких строк или много прочтений одиночных строк? – APC

Каковы ваши ожидания в отношении производительности/долговечности? Sharding? –

Вы забыли самую важную информацию: форму ваших данных. Если ваши данные не являются реляционными, тогда MySQL не может быть и речи, независимо от ваших требований к производительности. И если ваши данные * являются * реляционными, то SimpleDB и BigTable не могут быть и речи. У вас есть реляционные данные? Графические данные? Полуструктурированные данные документа? Иерархические данные? Данные онтологии/тройной/RDF?И я также согласен с @FractalizeR: вам нужны A, C, I, D? Если да, сколько или сколько вам нужно? Когда вам это нужно? Всегда ли эти потребности одинаковы или они отличаются от запросов к запросу? –

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

источник

2010-08-17 11:44:23 fredley

Является ли CouchDB подходящим для многих чтений и не пишет? Благодарю. – donald

Поскольку вы не используете записи во время работы, не имеет значения, насколько эффективно он не пишет :-). Однако из-за того, что он не выполняет транзакции или не управляет отношениями, накладные расходы меньше, чем другие, более сложные системы баз данных, такие как MySQL. Это примерно так же просто, как и получается, и это хорошо в этом случае. – fredley

Прочтите мое редактирование. – donald

-1

Я думаю, вы должны использовать не транзакционную и документальную базу данных, такую как MongoDB или CouchDB.

источник

2010-08-17 11:42:40

Можете ли вы подробно остановиться на этом? – donald

Что значит «много данных»? Тысячи, миллионы, миллиарды строк? Сколько и каких столбцов в строке? Будете ли вы использовать много объединений или простых выборок?

Если ваши таблицы просты или вам нужно использовать сложные JOIN, я бы выбрал любой SQL, с которым вы знакомы.

Если ваша структура сложна, и если база данных, ориентированная на документы, будет соответствовать вашим потребностям, я бы выбрал MongoDB (предпочтительно) или CouchDB.

Редактировать: Согласно вашему комментарию - тысячи строк не так уж много. Используйте свою любимую базу данных и установите столько кеша, сколько нужно (подробнее о нужной кеш-памяти или о новой теме). Или используйте Memcached, но я предлагаю использовать кеш базы данных, так как он эффективен и безболезнен для вас. Goog удачливый человек!

источник

2010-08-17 11:45:24 dwich

Тысячи строк. 20 столбцов в строке. Благодарю. – donald

Это даже близко к тому, чтобы быть большим. Шутки в сторону. Любой механизм базы данных будет соответствовать вашим потребностям. Даже бесплатный движок базы данных. –

Прочтите мое редактирование. – donald

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

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

AFAIK, SimpleDB и BigTable - это распределенные базы данных и предлагают очень хорошие скорости запросов, если ваши пользователи распределены географически (тем самым минуя сетевые задержки). Они не будут предлагать много преимуществ, если латентность ввода-вывода не является узким местом.

источник

2010-08-17 15:45:49 Moeb

Объем данных у вас крошечный. Любая СУБД будет справляться с несколькими тысячами строк. Я предлагаю вам сначала взглянуть на одну из популярных СУБД SQL, такую как MySQL, о которой вы уже говорили. Вам необходимо сделать выбор на основе функциональных требований, а не касаться размера данных.

источник

2010-08-17 20:10:18 sqlvogel

Какая база данных (ы) следует использовать для преимущественной записи один раз/Чтение Многие операции?

ответ

Смежные вопросы