Хранилище ключей-значений против RDBM против «облачных» БД (SDB) [закрыто]

Question

Я чувствую себя комфортно в пространстве MySQL, разработав несколько приложений за последние несколько лет, а затем постоянно совершенствуя аспекты производительности и масштабируемости. У меня также есть некоторый опыт работы с memcached для обеспечения ускорения на стороне приложения для часто запрашиваемых наборов результатов. А недавно я внедрил Amazon SDB в качестве своей основной базы данных. для эксперимента электронной коммерции.

Чтобы упростить задачу, я быстро пришел к выводу, что использование службы SDB заставило меня задуматься о том, что использование структуры базы данных без схемы позволит мне сосредоточиться на логической проблеме моего проекта и быстро накапливать контент в моем хранилище данных. , То есть не беспокойтесь о настройке и нормализации всех возможных перестановок атрибутов продукта перед этим; просто начните загрузку в продуктах, и SDB просто запомнит все, что доступно.

Теперь, когда мне удалось пройти первые несколько итераций моего проекта, и мне нужно настроить простые интерфейсы для данных, я столкнулся с проблемами, которые я принял как должное при работе с MySQL. Пример: группировка в операторах выбора и ограничение синтаксиса для запроса «элементов от 50 до 100». Преимущество легкости, которое я получил, используя SDB-архитектуру без схем, я потерял из-за снижения производительности, связанного с запросом / циклическим просмотром набора результатов с более чем 1800 элементами.

Сейчас я читаю о таких проектах, как Tokyo Cabinet, которые расширяют концепцию хранилищ ключей-значений в памяти, чтобы обеспечить псевдо-реляционную функциональность с невероятно высокой скоростью (14 раз я где-то читал).

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

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

Практический опыт работы с этими инструментами был бы очень признателен.

Спасибо ТАК!

Шахиб Р.

Answer 1

Новые решения не являются серебряными пулями.

По сравнению с традиционными СУБД, эти системы улучшают в некоторых аспектах (масштабируемость, доступность или простота) за счет компромисса других аспектов (сниженные возможности запросов, возможная согласованность, ужасная производительность для определенных операций).

Думайте об этом не как о замене традиционной базы данных, а как о специализированных инструментах для известной, конкретной потребности.

Например, Amazon Simple DB: SDB - это огромная электронная таблица. Если именно так выглядят ваши данные, то, вероятно, они работают хорошо, а превосходная масштабируемость и простота сэкономят вам много времени и денег.

Если вашей системе требуются очень структурированные и сложные запросы, но вы настаиваете на одном из этих крутых новых решений, вы скоро окажетесь в середине повторной реализации непрофессиональной, плохо спроектированной СУБД со всеми ее неотъемлемые проблемы.

В этом отношении, если вы не знаете, соответствуют ли они вашим потребностям, я думаю, что на самом деле лучше сделать первые несколько итераций в традиционной СУБД, поскольку они обеспечивают максимальную гибкость и возможности, особенно при развертывании на одном сервере. и под скромной нагрузкой. (см. теорему CAP ).

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

Если вам нужна простота облачного решения, но вам нужна реляционная база данных, вы можете проверить: Amazon Служба реляционной базы данных

Answer 2

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