У меня есть много вопросов о том, хранить ли мои данные в SQL или Table Storage и лучший способ их хранения для повышения эффективности.Вопросы по хранению данных в хранилищах SQL или таблиц
Use Case:
У меня есть около 5 миллионов строк объектов, которые в настоящее время хранятся в базе данных MySQL. В настоящее время метаданные хранятся только в базе данных. (Lat, Long, ID, Timestamp). Остальные 150 столбцов об объекте, которые не используются много, были перемещены в хранилище таблиц.
- В хранилище таблиц, должны ли они храниться в одной строке со всеми 150 столбцами, которые не используются в одном столбце, а не в нескольких строках?
Для каждого из этих 5 миллионов объектов в базе данных есть определенная информация о них (показания температуры, траектории и т. Д.). Данные траектории, используемые для хранения в SQL (~ 300 строк/объектов), но были перемещены в хранилище таблиц, были экономически эффективными. В настоящее время они хранятся в хранилище таблиц реляционным способом, где каждая строка выглядит (PK: ID, RK: ID-Depth-Date, X, Y, Z).
- В настоящее время требуется много времени для получения данных о траекториях. Настольное хранилище в нашем случае довольно медленное. Я хочу улучшить производительность получателей. Должны ли данные храниться там, где каждый объект имеет 1 строку для своей траектории, и все XYZ хранятся в 1 столбце в формате JSON? Вместо 300 строк, которые нужно получить, нужно только получить 1 строку.
- Является ли хранилище таблиц лучшим местом для хранения всех этих данных? Если бы я хотел получить X, Y, Z на определенной измеренной глубине, мне пришлось бы получить всю строку и разобрать через JSON. Это, вероятно, компромисс.
- Возможно ли иметь данные траектории, показания и т. Д. В базе данных sql, где для данных траектории может быть (5 000 000 x 300 строк). Также есть информация об объектах, где это может быть (5 000 000 x 20 000 строк). Это, вероятно, слишком много для базы данных SQL и должно быть в хранилище Azure CLoud. Если да, будет ли вариант JSON лучшим? Компромисс заключается в том, что если я хочу часть, которая составляет 1000 строк, мне придется получить всю таблицу, однако, это не так быстрее, чем запрос через 20 000 строк. Возможно, я могу разбить данные на наборы из 1000 строк и использовать sql в качестве метаданных для определения того, какие наборы данных мне нужны из облачного хранилища.
У меня возникли проблемы с пониманием того, как группировать данные и форматировать их в Azure Cloud Tables, чтобы быть эффективными и быстрыми при захвате данных для моего приложения.
Вот пример моих данных и как я получаю это: http://pastebin.com/CAyH4kHu
Вы просите совета по использованию одного из трех двигателей и типов баз данных: MySQL (реляционные), хранилища таблиц (ключ/значение) и DocumentDB (документ). И вы просите совета о том, как расположить строки данных и т. Д. Это даст вам мнение, поскольку нет единого правильного ответа. Таким образом, к сожалению, этот тип вопроса не подходит для StackOverflow. –
@DavidMakogon Я задаю общий вопрос о том, как большие данные должны храниться в лазурной таблице для повышения эффективности. Я откажусь от documentDB и удаляюсь от части базы данных sql, чтобы перейти к вопросу, который соответствует SO. –
Это поможет предоставить больше контекста ... Можете ли вы предоставить пример данных и то, что шаблоны чтения/записи (например, первые 1-3 запроса)? Я был бы рад провести более подробное обсуждение этого вопроса ... Почему так много столбцов - все они заполнены для каждой строки? Должно ли это учитывать изменчивость в том, какие поля заполняются для каждой строки? Вам нужно запрашивать эти поля? –