Как показать только данные, которые пользователь импортировал в табличную модель - PullRequest
0 голосов
/ 14 июня 2019

Итак, я столкнулся с некоторыми архитектурными проблемами.

Я создал табличную модель в службе анализа, и одна из моделей имеет структуру ценообразования, данных и т. Д.

Моя система позволяет импортировать для пользователя данные, содержащие миллионы записей. Но я не знаю, какая структура самая лучшая. Я должен показывать на конечной точке API (ASP.NET CORE) данные, импортированные пользователем, но не данные других пользователей, поэтому должен ли я иметь новый столбец идентификаторов, чтобы я мог знать, принадлежат ли данные текущему пользователю?

А может есть варианты получше? Может быть, хранить для каждого пользователя данные о новой таблице и новой табличной модели?

1 Ответ

1 голос
/ 17 июня 2019

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

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

  • 100 пользователей
  • 500 тыс. Записей на пользователя
  • 2 столбца (идентификатор пользователя и столбец данных)
  • 10 тыс. Уникальных значений в нашем столбце данных

В традиционной реляционной базе данных у нас будет

  • 100 пользователей x 500 тыс. Записей = 50 миллионов единиц (ай!)

Если бы мы поместили каждого пользователя в уникальную таблицу или модель в виде таблицы, то мы получили бы

  • 100 моделей (пользователей) x 10k уникальных значений = 1 миллион элементов (вероятно, немного меньше, поскольку каждый пользователь может иметь не все значения 10k)

Однако, если мы создадим одну таблицу с идентификатором пользователя и столбцом данных, мы получим

  • 100 пользователей в магазине с одним столбцом + 10 000 уникальных значений в другом магазине = 10 100 наименований

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

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

Надеюсь, этого достаточно, чтобы вы начали. Если вы хотите узнать больше о том, как организовать ваши данные, чтобы быть эффективными в табличной модели, я бы посоветовал узнать, как работает схема снежинка . Для таблиц служб аналитики, в частности, Парень в кубе и sqlbi.com являются отличными ресурсами. Большая часть их контента посвящена Power BI, но модели данных Power BI - это просто табличные кубы. Они оба используют движок Vertipaq для хранения и запроса данных.

...