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


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

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

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

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

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

8 52

8 ответов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

библиотека .NET-это Простой Савант.

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

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

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

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

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

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

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