Альтернативы для хранения лазурных таблиц

Question

Мы использовали гибридную архитектуру в Windows Azure, сохраняя большинство объектов в базе данных SQL Azure, но бросая все, что может потребовать значительных объемов пространства для хранения в Azure Table Storage.

С этой архитектурой мы сталкиваемся с множеством проблем с Azure Table Storage, которая в лучшем случае поражает меня как незрелого и неполного продукта. Самое большое ограничение заключается в том, что для всех практических целей это хранилище данных только для записи. Консенсус в том, что возможности его записи очень хорошо масштабируются, но его возможности запросов и индексирования настолько удивительно ограничены (несмотря на годы users complaining and Microsoft promising), что я пришел к выводу, что вы должны в основном пытаться извлечь данные из ATS в чрезвычайная ситуация. Получение данных из него для сложного, реального времени, транзакционного приложения для производства намного сложнее, чем должно быть. Конечно, есть обходные пути, например, сохранение нескольких копий данных с разными стратегиями индексирования для каждой копии или разделение ваших запросов и их параллельное выполнение, но это добавляет сложности, когда вся точка облачного сервиса заключается в ее минимизации.

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

Я вполне хорошо знаю, что есть много вариантов NoSQL (например, все перечисленные в этом вопросе: What NoSQL solutions are out there for .NET?), которые я могу запускать либо на виртуальной машине, либо в каком-либо другом облаке. Но мне особенно интересно узнать, есть ли что-то, что хорошо вписывается в модель PAAS от Azure. Другими словами, если я нахожусь на Azure и не хочу управлять своими собственными виртуальными машинами и хочу как можно ближе к почти автоматической и почти бесконечной масштабируемости, обещанной (хотя и не доставляемой) ATS, какие варианты имеют люди нашли ценный? Является ли MongoDB/Azure wrapper простой и жизнеспособной альтернативой? Или я должен просто укусить пулю и развернуть свои собственные ВМ? Или переключиться на AWS? Или придерживаться Azure SQL?

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

Answer 1

Мы прошли через аналогичную ситуацию и исследовали несколько вариантов, которые предлагают варианты Azure и nosql.

Мера, которую мы взяли, заключалась в использовании Azure Blob Storage и Lucene.Net. Мы сериализуем наши объекты в Json, а затем сохраняем их в AzureBlobs.

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

Answer 2

Хотя хранилище таблиц Azure не поддерживает вторичные индексы и не имеет набора функций SQL, оно не пытается решить ту же проблему.

Я бы избегал SQL Azure (или что бы то ни было, что он называется сейчас), и сосредоточиться на создании слоя данных, который использует то, что Azure подходит (blobs, tables, and queues).

Мы обнаружили, что столовое хранилище является более чем достаточным для крупного производственного решения. За последние 18 месяцев он стал намного лучше. V2 клиентской библиотеки .NET намного лучше, чем v1.

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

Я согласен с предыдущим сообщением, что что-то вроде Lucene может быть хорошим, если вам нужно индексировать большое количество данных. Мы находим, что с помощью таблиц и blobs мы можем обойтись без, но это определенно вариант в вашем наборе инструментов.

Answer 3

Azure добились больших успехов в NoSQL, так как это было опубликовано. Теперь вы можете раскручивать Raven и MongoDB в качестве аддонов из Azure, и они недавно объявили «Azure DocumentDB» своим собственным предложением. Это в общественном просмотре - блог здесь: http://azure.microsoft.com/blog/2014/08/21/new-azure-services-and-updates-expand-openness-choice-and-flexibility/

Дополнительная информация и документация доступна здесь: http://azure.microsoft.com/en-gb/services/documentdb/

Как уже упоминалось, Lucene в качестве возможного решения поиск/индекс. У меня есть веб-сайт на сайтах Azure, которые используют индекс Lucene для поиска, и я смог хранить и запрашивать индекс непосредственно на веб-пространстве веб-сайта, поэтому не нуждался в выделенной виртуальной машине или беспокоиться о том, как я показываю индекс через провод. Очевидно, что это может оказаться сложным, если вы хотите поддерживать несколько веб-боксов (при масштабировании), но это может стоить вам знать как возможность. Мой веб-экземпляр поставляется с 50 ГБ дискового пространства, из которых лишь небольшая часть используется веб-сайтом, поэтому индекс Lucene использует его. Я никогда не слышал, чтобы это была официальная стратегия, YMMV.

Answer 4

Может быть, немного от темы.

Существует несколько вариантов использования, где ATS - отличный инструмент.

В одном случае хранятся метаданные, которые вы обычно храните как сериализованные объекты XML (JSON) в вашей обычной RDB. Это данные, которые не требуют индексации, но структурированы. Например, все метаданные клиента. Причиной использовать скорее ATS, чем SQL, является способность ATS добавлять, удалять столбцы таких данных на ходу. Поэтому всякий раз, когда вы меняете структуру метаданных, вам не нужно перебирать все записи клиента, десериализовать XML (JSON), воссоздавать дерево данных, сериализовывать его в XML (JSON) и хранить обратно в таблицу. Это потрясающе. Нижняя сторона монеты - вы должны сохранить плоскую структуру метаданных вместо древовидной структуры, которую вы можете достичь, используя классическую сериализацию XML (JSON).

Второй случай - это хранение данных с вашего RDBM, который вам не нужен, если их слишком много. Это может быть, например, список транзакций в банковской системе старше 5 лет. Это данные, которые вам нужно хранить, но не в активной форме. Эти данные замедлят ваши соединения/условия, и вы не нуждаетесь в них на ежедневной основе. Вы можете вернуть эти данные или переместить их в другой RDBM для автономного анализа, сделанного один раз в год. Хранение данных в ATS также намного дешевле, чем оставлять их внутри RDBM.