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

Ответ 1

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

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

Для текстовых данных, ограниченных 10k, я бы рекомендовал хранить их непосредственно в SimpleDB. Он будет легко вписываться в один элемент, но вам придется распространять его по нескольким атрибутам. В принципе, есть два способа сделать это с некоторыми отступами.

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

- Том

Ответ 4

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

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

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

Ответ 5

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

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

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

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