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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

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

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

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

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

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