Какой смысл использовать Amazon SimpleDB?

Question

Я подумал, что мог бы использовать SimpleDB для того, чтобы позаботиться о самой сложной области моего приложения (в том, что касается масштабирования) - твиттероподобных комментариев, но с расположением сверху - до того момента, когда я сел, чтобы фактически начать реализуя его с SDB.

Во-первых, SDB имеет ограничение 1000 байтов на значение атрибута, которого недостаточно даже для комментариев (вероятно, необходимо разбить более длинные значения на несколько атрибутов).

Тогда максимальный размер домена составляет 10 ГБ. Было обещано, что вы можете масштабироваться, не беспокоясь о разбиении базы данных и т. Д., Поскольку SDB не будет ухудшаться при увеличении загрузки данных. Но если я правильно понимаю, с доменами у меня будет точно такая же проблема, как с шардингом, т.е. в какой-то момент необходимо реализовать распределение записей данных и запросы по доменам на уровне приложений.

Даже для самых простых объектов, которые у меня есть во всем приложении, т.е. атомарные пользовательские рейтинги, SDB не вариант, потому что он не может вычислить среднее значение в запросе (все основано на строке). Таким образом, чтобы рассчитать среднюю пользовательскую оценку для объекта, мне нужно было бы загрузить все записи - 250 за раз - и рассчитать их на уровне приложения.

Я что-то упускаю из SDB? Действительно ли 10 ГБ - это большая часть базы данных, чтобы преодолеть все ограничения SDB? Я был искренне в восторге от использования SDB, поскольку я уже использую S3 и EC2, но сейчас я просто не вижу варианта использования.

Answer 1

Я использую SDB для нескольких приложений большого размера. Ограничение в 10 ГБ на домен меня действительно беспокоит, но мы играем на Amazon, позволяя расширить его, если нам это нужно. У них есть форма запроса на их сайте, если вам нужно больше места.

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

Ограничение в 1000 байт на атрибут также было сложно обойти. Одно из приложений, которое у меня есть, - это сервис блогов, который хранит записи и комментарии в базе данных. При переносе на SDB я столкнулся с этим ограничением. В итоге я сохранил записи и комментарии в виде файлов в S3 и прочитал это в своем коде. Поскольку этот сервер находится на EC2, трафик на S3 ничего не стоит.

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

Все это говорит, я все еще люблю SDB. Я не жалею о переходе на это. Я перешел с сервера SQL 2005. Я думаю, что у меня было намного больше контроля над SQL, но как только я откажусь от него, у меня будет больше гибкости. Не нужно предварительно определять схему - это круто. Сильный и надежный уровень кэширования в вашем коде позволяет легко сделать SDB более гибким.

Answer 2

У меня около 50 ГБ в SimpleDB, разделенных на 30 доменов. Я использую это для разрешения нескольких ключей на объектах, хранящихся в S3, а также для снижения моих затрат на S3. Я не играл с использованием SimpleDB для полнотекстового поиска, но я бы не стал пытаться.

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

Вот описание того, как я зажимаю копейки с помощью SimpleDB

Answer 3

Стоит добавить, что хотя написание собственной логики шардинга для разных доменов не является идеальным, это с точки зрения производительности. Например, если вам нужно выполнить поиск по 100 ГБ данных, лучше попросить 20 машин, каждый из которых имеет 5 ГБ, выполнить тот же поиск в той части, за которую они отвечают, а не одному компьютеру, выполняющему всю задачу. Если ваша цель - получить отсортированный список, вы можете взять лучшие результаты, полученные из 20 одновременных запросов, и сопоставить их на компьютере, инициирующем запрос.

Тем не менее, я бы хотел видеть это абстрагированным от обычного использования и иметь что-то вроде "подсказок" в API, если вы хотите получить более низкий уровень. Поэтому, если вам удастся сохранить 100 ГБ данных, позвольте Amazon решить, будет ли он разделен на 20 машин или 10 или 40, и распределить работу. Например, в дизайне Google BigTable по мере роста таблицы она постоянно разбивается на планшеты по 400 Мб. Запросить строку из таблицы так же просто, как и BigTable, чтобы выяснить, где находится один планшет или миллионы планшетов.

С другой стороны, BigTable требует от вас писать вызовы MapReduce для выполнения запроса, в то время как SimpleDB индексирует себя динамически для вас, поэтому вы выигрываете, а некоторые теряете.

Answer 4

Amazon пытается заставить вас реализовать простую объектную базу данных. Это в первую очередь по соображениям скорости. Думайте о записях SimpleDB как о указателе / ​​ключе к элементу в S3. Таким образом, вы можете запускать запросы (медленнее, чем SimpleDB, чтобы получить списки результатов, или вы можете напрямую нажимать клавишу S3 (быстро), чтобы вытащить объект, когда вам нужно получить или изменить записи по одному за раз.

Answer 5

Если проблема связана с размером хранилища для каждого атрибута, вы можете использовать S3 для хранения больших данных и сохранять ссылки на объекты s3 в SDB. S3 не только для файлов, это универсальное решение для хранения.

Answer 6

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

• Прозрачное разбиение данных
• Псевдотранзакционность
• Прозрачный охват атрибутов для превышать предел в 1000 байт

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

.NET-библиотека Simple Savant .

Answer 7

Похоже, что ограничения применяются к текущей версии Beta . Я предполагаю, что они позволят большие базы данных в будущем, после того, как они выяснят, как они могут удовлетворить спрос экономически. Даже с учетом ограничений база данных объемом 10 ГБ, которая поддерживает высокую масштабируемость и надежность, является полезным и экономически эффективным ресурсом.

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

Amazon SimpleDB также предлагает бесплатный уровень обслуживания , так что вы можете хранить до 1 ГБ, передавать до 1 ГБ в месяц, используя до 25 часов машинного времени. Хотя этот предел звучит очень низко, тот факт, что он бесплатный, позволяет небольшим клиентам использовать эту технологию, не вкладывая средства в большую ферму серверов.

Answer 8

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

Итак, ограничения, которые я видел:

• может быть запущен только на Amazon AWS, вы также должны платить за целую группу сотрудников
• максимальный размер домена (таблицы) составляет 10 ГБ
• длина значения атрибута (размер поля) составляет 1024 байта
• максимальное количество элементов в выбранном ответе - 2500
• максимальный размер ответа для Select (максимальный объем данных, который может вам вернуть) - 1Mb, на самом деле вы можете проверить все ограничения здесь
• имеет драйверы только для для нескольких языков (java, php, python, ruby, .net)
• не разрешает поиск без учета регистра. Вы должны ввести дополнительную строчную логику / логику приложения.
• сортировка может быть выполнена только на одном поле
• из-за ограничения по времени 5с счет может вести себя странно . Если прошло 5 секунд, а запрос еще не завершен, вы получите неполный номер и токен, позволяющий продолжить запрос. Прикладная логика отвечает за сбор всех этих данных и суммирование.
• все является строкой UTF-8 , что затрудняет работу с нестроковыми значениями (такими как числа, даты).
• сортировка ведет себя странно для чисел (из-за того, что все является строкой). Так что теперь вы должны сделать шаманский танец с заполнением
• у обоих нет транзакций и присоединений
• без составных, геостатических, многостолбечных индексов, без внешних ключей

Если этого недостаточно, вам также придется забыть об основных вещах, таких как group by, sum average, distinct, а также о манипулировании данными. В целом язык запросов довольно прост и напоминает небольшое подмножество возможностей SQL.

Таким образом, функциональность на самом деле не намного богаче, чем у Redis / Memcached, но я очень сомневаюсь, что он работает так же хорошо, как эти две базы данных в их случаях использования.

SimpleDB позиционирует себя как база данных nosql без схемы, но синтаксис запросов MongoDB / CounchDB более выразителен, а их ограничения более разумны.

И наконец - не забудьте о блокировке вендора . Если через пару лет Azure (или что-то еще появившееся) предоставит облачный хостинг в 5 раз дешевле, чем AWS, переключиться будет очень сложно.