#azure #multi-tenant #azure-iot-hub #azure-stream-analytics
Вопрос:
Я создаю приложение Azure IoT Hub. У меня есть несколько клиентов, у каждого из которых есть набор устройств. Как вы думаете, все эти клиенты должны быть подключены к одному и тому же концентратору или к другому (ам)?
Я хотел бы заполнить многопользовательскую базу данных (одну базу данных, несколько схем) с помощью azure stream analytics. Идея состоит в том, чтобы использовать задание, которое разбивает данные по клиентам и сохраняет их в таблице определенной схемы (схемы, связанной с конкретным клиентом) в моей БД. Это возможно сделать, или единственный способ разделить данные о клиентах-это иметь несколько БД (вместо одной БД и нескольких схем)?
Ответ №1:
Я создаю приложение Azure IoT Hub. У меня есть несколько клиентов, у каждого из которых есть набор устройств. Как вы думаете, все эти клиенты должны быть подключены к одному и тому же концентратору или к другому (ам)?
Это действительно зависит от обрабатываемых данных, а также от ваших фактических требований. Если совместное использование сведений о ресурсах Центра интернета вещей с другими клиентами не является проблемой, вы можете использовать тот же центр интернета вещей. В противном случае выберите отдельные центры интернета вещей.
Я хотел бы заполнить многопользовательскую базу данных (одну базу данных, несколько схем) с помощью azure stream analytics. Идея состоит в том, чтобы использовать задание, которое разбивает данные по клиентам и сохраняет их в таблице определенной схемы (схемы, связанной с конкретным клиентом) в моей БД. Это возможно сделать, или единственный способ разделить данные о клиентах-это иметь несколько БД (вместо одной БД и нескольких схем)?
Выходные данные SQL в Azure Stream Analytics поддерживают параллельную запись в качестве опции. Эта опция позволяет использовать полностью параллельные топологии заданий, в которых несколько выходных разделов параллельно записываются в целевую таблицу. Однако включение этого параметра в Azure Stream Analytics может оказаться недостаточным для повышения пропускной способности, поскольку это в значительной степени зависит от конфигурации базы данных и схемы таблиц. Выбор индексов, ключ кластеризации, коэффициент заполнения индекса и сжатие влияют на время загрузки таблиц. Дополнительные сведения о том, как оптимизировать базу данных для повышения производительности запросов и загрузки на основе внутренних тестов, см. в руководстве по производительности базы данных SQL. Порядок записи не гарантируется при параллельной записи в базу данных SQL.
Дополнительные сведения см. в разделе Повышение производительности базы данных SQL Azure с помощью Azure Stream Analytics.
Комментарии:
1. Спасибо за ответ. Клиенты не будут иметь доступа к данным, кроме как через приложение, которое будет использовать базу данных azure. Я хотел бы убедиться, что поток данных, поступающий с набора устройств (клиента A), через Stream Analytics попадает в таблицу в схеме A моей базы данных. Аналогично, для клиента B (в схеме B моей базы данных, obv). Таблица имеет одинаковую структуру в каждой схеме, и клиенты не видят данные друг друга (это делается с помощью механизма выбора схемы, выполняемого моим приложением).
2. Чтобы привести вам пример, я хочу понять, можно ли сделать что-то подобное в запросе преобразования: выберите * в [A]. [таблица] из ввода, где клиент = ‘A’; выберите * в [B]. [таблица] из ввода, где customer = ‘B’; (где [A] — имя схемы моей базы данных и [таблица] — имя таблицы) Я также согласен с тем, что каждое утверждение является частью определенного потока.
3. Вы, конечно, можете это сделать, но обратите внимание, что вам нужно будет создать один вывод в ASA для каждой комбинации схемы/таблицы (так что 2 в вашем примере, один для A, один для B). Это может не очень хорошо масштабироваться в вашем случае (плюс у нас есть жесткое ограничение на количество выходов на задание).
4. Я бы вывел все данные из ASA в единую целевую таблицу в SQL, а затем распределил бы данные в SQL. Альтернативой, если ваша модель затрат позволяет это, является выделение задания ASA для каждого клиента вместо этого и инвестирование в конвейер выпуска, чтобы вы могли предоставить эти задания как можно проще.
5. Большое спасибо за ответ 🙂 Итак, если я правильно понимаю, лучшим решением было бы создание отдельных рабочих мест для каждого клиента (так что, чем больше клиентов, тем больше рабочих мест). Еще одно приемлемое решение с меньшими затратами-ввести данные в одну таблицу с помощью одного задания ASA, а затем разделить эти данные на правильную схему с помощью sql. Вы бы сделали это по-другому?