максимальный размер атрибутов в AWS SimpleDB

Question

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

В моем случае нам нужно хранить от 1024 до 10К текстовых данных.

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

По-моему, я не уверен, является ли SimpleDB правильным решением. Может ли кто-нибудь прокомментировать, что это сделало, или предложить другой способ решения этой проблемы?

Answer 1

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

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

Для текстовых данных, ограниченных 10 КБ, я бы рекомендовал хранить их непосредственно в SimpleDB. Он легко поместится в один элемент, но вам придется распределить его по нескольким атрибутам. Есть два основных способа сделать это, каждый из которых имеет свои недостатки.

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

Тот факт, что весь текст хранится в одном атрибуте, облегчает выполнение запросов с одним именем атрибута в предикате. Вы можете добавить различный размер текста к каждому элементу в любом месте от 1k до 200 + k, и он обрабатывается соответствующим образом. Но вы должны знать, что ваши предварительно добавленные номера строк могут оказаться положительными для ваших запросов (например, если вы ищете 01, каждый элемент будет соответствовать этому запросу).

Второй способ хранения текста в SimpleDB не требует, чтобы вы помещали данные произвольного порядка в ваши текстовые блоки. Вы делаете упорядочение, помещая каждый текстовый блок в другой названный атрибут. Например, вы можете использовать имена атрибутов: desc01 desc02 ... desc10. Затем вы помещаете каждый кусок в соответствующий атрибут. Вы все еще можете выполнять полнотекстовый поиск с обоими методами, но поиск будет медленнее с этим методом, потому что вам нужно будет указать много предикатов, и SimpleDB завершит поиск по отдельному индексу для каждого атрибута.

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

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

Answer 2

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

Сколько значений вы можете хранить в одном атрибуте в одной «строке» (имени)? Я посмотрел в документах, никакой ответ не выскочил на меня.

- Том

Answer 3

Если вас беспокоит стоимость, вы можете обнаружить, что дешевле поместить текст в S3 и метаданные с указателями в SimpleDB.

Answer 4

SimpleDb, ну просто. Все в нем - строка. Документация очень проста. И есть много ограничений использования. Такие как:

• Вы можете сделать SELECT * FROM ___ WHERE ItemName() IN (...) только с 20 ItemName с в IN.
• Вы можете PUT (обновить) одновременно не более 25 записей.
• Все чтения основаны на времени вычислений. Поэтому, если вы делаете SELECT с LIMIT из 1000, оно может вернуть что-то вроде 800 (или даже ничего) вместе с nextToken, в котором вам нужно сделать дополнительный запрос (с nextToken). Это означает, что следующий SELECT может фактически возвращать счетчик пределов, поэтому сумма возвращенных строк из двух SELECT может быть больше, чем ваш исходный предел. Это вызывает беспокойство, если вы выбираете много. Кроме того, если вы сделаете SELECT COUNT(*), вы столкнетесь с аналогичной проблемой. Он вернет вам счет вместе с nextToken. И вам нужно продолжать повторять эти nextToken s и суммировать возвращаемые значения, чтобы получить истинное (общее) количество.
• Все эти времена вычислений будут в значительной степени зависеть от больших данных в хранилище.
• Если у вас будет большое количество записей, вам, вероятно, придется разделять записи на несколько доменов
• Amazon отрегулирует ваши запросы, если вы сделаете слишком много на одном домене

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

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

Answer 5

Предстоящий выпуск Simple Savant (созданная мной библиотека персистентности C # для SimpleDB) будет поддерживать охват атрибутов, как описано в Mocky, и полнотекстовый поиск данных SimpleDB с использованием Lucene.NET.

Я понимаю, что вы, вероятно, не создаете свое приложение на C #, но, поскольку ваш вопрос является лучшим результатом при поиске SimpleDB и полнотекстовой индексации, стоит упомянуть.

ОБНОВЛЕНИЕ: упомянутая выше версия Simple Savant теперь доступна.