Пригодность Amazon SimpleDB для больших временных наборов данных, исходящих от тысяч отдельных устройств

Question

Я пытаюсь установить, подходит ли Amazon SimpleDB для подмножества данных, которые у меня есть.

У меня есть тысячи развернутых автономных сенсорных устройств, которые записывают данные.

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

Сегодня строки данных в SQL выглядят примерно так:

• (идентификатор, идентификатор_устройства, utc_timestamp, значение1, значение2)

Наше существующее решение MySQL не будет расширяться с десятками миллионов строк. Мы запрашиваем такие вещи, как « подскажите мне сумму всех значений1 вчера » или « покажите мне среднее значение value2 за последние 8 часов ». Мы делаем это в SQL, но можем с радостью перейти на код. SimpleDBs "возможная согласованность" выглядит хорошо для наших целей.

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

Является ли SimpleDB подходящим средством для этого и каким будет обобщенный подход?

PS: Мы в основном используем Python, но это не должно иметь значения при рассмотрении этого вопроса на высоком уровне. На данный момент мне известна библиотека boto .

Edit:

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

Answer 1

Просто продолжая эту тему много месяцев спустя ...

У меня действительно была возможность поговорить напрямую с Amazon об этом прошлым летом, и в итоге я получил доступ к бета-программе для того, что в итоге стало DynamoDB, но не смог об этом поговорить.

Я бы порекомендовал его для такого рода сценариев, где вам нужен первичный ключ и что может быть описано как вторичный индекс / диапазон - например, временные метки.Это дает вам гораздо большую уверенность в поиске, то есть «покажите мне все данные для устройства X между понедельником и пятницей»

На самом деле мы еще не перешли к этому по разным причинам, но все еще планируем.

http://aws.amazon.com/dynamodb/

Answer 2

По моему мнению, Amazon SimpleDb, а также таблицы Microsoft Azure являются хорошим решением, если ваши запросы довольно просты. Как только вы пытаетесь делать вещи, которые абсолютно не проблема в реляционных базах данных, таких как агрегаты, вы начинаете сталкиваться с проблемами. Так что, если вы собираетесь делать какие-то тяжелые репортажи, это может запутаться.

Answer 3

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

Answer 4

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