SQL имеет значение порядок вставки строк? - PullRequest
Новая
       10

SQL имеет значение порядок вставки строк?

0 голосов
/ 05 июля 2018

Я новичок в БД, впервые исследующий хранилище данных. Я завершил процесс копирования большого объема данных из одной из наших производственных систем (MS SQL Server 2012) в наше хранилище данных (MySQL).

Проблема, с которой я столкнулся, заключалась в том, что программные / аппаратные ресурсы, которые у меня были доступны для процесса ETL, не были достаточно надежными для копирования всех данных в моих больших таблицах с помощью одного запроса (программе не хватало памяти и происходил сбой) , Чтобы обойти это, я разбил эти таблицы на 12 частей, добавив предложение where с помощью оператора modulo для идентификатора таблицы, поскольку это было быстро и легко написать: 

SELECT * FROM table WHERE table.tableID % 12 = 0;
SELECT * FROM table WHERE table.tableID % 12 = 1;
SELECT * FROM table WHERE table.tableID % 12 = 2;
etc.

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

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

Попал ли я в беду, копируя и вставляя данные таким образом?

Ответы [ 2 ]

0 голосов
/ 05 июля 2018

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

|  DateTime        | Product | QTY |
| ---------------- | --------|-----|
| 2018-03-05 10:50 |  prod1  |  5  |

таблица с 10 ^ 8 записями. Может быть, вы хотите хранить только количество продуктов на дату, имея что-то вроде этого: 

|    Date    |     Qty     |
|------------|-------------|
| 2018-03-05 |    10000    |

Это уменьшит количество элементов вашей таблицы и повысит эффективность вашего приложения

0 голосов
/ 05 июля 2018

Это, вероятно, не будет иметь значения. Как правило, базы данных могут использовать преимущества порядка в таблице, когда объявляется кластерный индекс (какого-либо рода). Если у вас есть один объявленный, то данные будут упорядочены на страницах данных, независимо от порядка вставки. Если у вас его нет, оптимизатор не сможет воспользоваться заказом.

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

В некоторых случаях упорядочивание данных может давать результаты, которые кажутся правильными, но это «плохой» SQL:

  • Запрос, в котором нет предложения ORDER BY, но ожидаются результаты в определенном порядке.
  • Запрос, использующий MySQL (функция), который допускает неагрегированные неключевые столбцы в SELECT запроса агрегации.
  • Запрос, который зависит от порядка значений в GROUP_CONCAT(), у которого нет предложения ORDER BY.

Это «плохо», потому что они зависят от наблюдаемого поведения системы, а не от задокументированного поведения (и, без сомнения, я, возможно, пропустил некоторые из них).

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

...