Мнение стека облачной архитектуры - EC2 против Azure

Question

Я прочитал много блогов и статей о плюсах и минусах Amazon EC2 против Microsoft Azure (и Google App Engine ).Однако я пытаюсь решить, какой вариант лучше подойдет для моего конкретного случая.

У меня есть набор данных, который можно рассматривать как стандартную таблицу формата:

[id]  [name]  [d0]  [d1]  [d2] .. [d63]
---------------------------------------
0     Name1   0.43 -0.22  0.11   -0.81
1     Name2   0.23  0.65  0.62    0.41
2     Name3  -0.13 -0.23  0.17    0.00
...
N     NameN   0.43 -0.23  0.12    0.01

Iв конечном счете, мы хотим сделать что-то, что (несмотря на мой последний выбранный стек) будет равно выражению SQL SELECT, похожему на:

SELECT name FROM [table] WHERE (d0*QueryParameter1) + (d1*QueryParameter1) +(d2*QueryParameter2) + ... + (dN*QueryParameterN) < 0.5

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

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

Я могу сделать это несколькими способами:

• (1) Использовать SQL Azure , так же, как запрос выше.Я попробовал этот метод, и запросы могут быть довольно медленными, как и ожидалось, поскольку SQL дает вам только один экземпляр.Я могу раскрутить несколько экземпляров SQL и разделить данные на части, но это очень быстро и очень дорого.
• (2) Использование Таблицы хранилища Azure .Блоггеры утверждают, что таблицы хранения в целом работают быстрее, но будет ли это соответствовать моим требованиям?
• (3) Использовать EC2 и ускорять несколько экземпляров с помощью MySQL возможно добавление шардинга для новых экземпляров (хотя стоимость увеличивается).
• (4) Используйте EC2 с MongoDB , поскольку я читал, что это быстрее, чем MySQL.Опять же, это, вероятно, зависит от типа запроса.
• (5) Google AppEngine. Я не совсем уверен, как GAE будет работать с этой структурой запроса, но я думаю, именно поэтому яищу мнения.

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

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

Cheers, Brett

Answer 1

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

Другими словами, вам нужна НЕ база данных SQL, а база данных NoSQL.который действительно оптимизирует доступ к таблице / строке с максимально возможной скоростью.Так что вам действительно не нужно пытаться использовать SQL Azure и MySQL, чтобы узнать эту часть ответа.

Кроме того, каждая строка в вашем типе запроса полностью независима друг от друга, поэтому она легко поддается простомупараллелизм.Выбор платформы должен быть таким, который дает вам:

1. Сканирование таблицы / строки на максимальной скорости
2. Возможность высокой степени параллелизации вашей операции

Каждая платформаВы упомянули, что вы можете хранить огромное количество больших двоичных или табличных данных для очень быстрого поиска при сканировании (например, хранение таблиц в Azure).Каждый из них также дает вам возможность «раскрутить» несколько экземпляров, чтобы обрабатывать их параллельно.Это действительно зависит от того, в какой среде программирования вы чувствуете себя наиболее комфортно (например, Java в Google / Amazon, .NET в Azure).По сути, все они делают одно и то же.

Моя личная рекомендация - Azure, поскольку вы можете:

1. Хранить большие объемы данных в «табличном хранилище», оптимизированном для быстрого поиска при сканировании.и секционируется (например, по диапазонам d0) для оптимального параллелизма
2. Динамически «раскручивает» столько вычислительных экземпляров, сколько вам нужно, чтобы обрабатывать данные параллельно
3. Механизмы очереди для синхронизации сортировки результатов

Azure делает то, что вам нужно, очень "без излишеств" - предоставляя вам достаточно инфраструктуры для выполнения вашей работы и ничего более.

Answer 2

Проблема не в математических операторах или их количестве, проблема в том, что они параметризованы - вы эффективно выполняете взвешенное среднее по столбцам с весами, определяемыми во время выполнения, так что операция должна быть вычислена и не может быть выведен.

Даже в SQL Server эту операцию можно распараллелить (и это должно отображаться в плане выполнения), но она не поддается поисковой оптимизации с использованием индексов, в которых в действительности будет сиять большинство реляционных баз данных. Со статическими весами и индексированным вычисляемым столбец, очевидно, будет работать очень быстро.

Поскольку эту проблему легко распараллелить, вы можете захотеть взглянуть на что-то, основанное на принципе Map-Reduce .

Answer 3

Если предположить, что QueryParameter0, QueryParameter1, ..., QueryParameterN все поставляются во время выполнения и каждый раз отличаются, то я не думаю, что какая-либо из платформ сможет обеспечить существенные преимущества по сравнению с любой другой - поскольку ни один из них не сможет воспользоваться какими-либо предварительно вычисленными признаками.

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

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

---

Обновление - только что видел ответ от @Cade тоже - +1 за предложение параллелизации.

Answer 4

В настоящее время ни SQL Azure, ни Amazon RDS не могут масштабироваться по горизонтали (EC2 может, по крайней мере, по вертикали), но ЕСЛИ и только ЕСЛИ ваши данные могут быть разбиты таким образом, чтобы все еще было возможно выполнить ваш запрос предстоящей функции федерации SQL в SQL Azure. возможно, стоит посмотреть и помочь принять обоснованное решение.

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