много столбцов в таблице

Question

Таблица в нашей схеме уже содержит 100 столбцов. Нам нужно добавить еще 600 столбцов, если мы будем следовать горизонтальному методу хранения данных. Если мы будем использовать вертикальное хранилище данных, что означает создание новой таблицы и создание ссылочной целостности с таблицей, содержащей 100 столбцов, будет проблема с присоединением к таблице, поскольку таблица, содержащая 100 столбцов, имеет 53 миллиона записей, а новая созданная таблица будет иметь гораздо больше чем это. Что лучше подходит в этом случае.

Я хочу добавить здесь интересный тестовый пример. Я добавил 600 столбцов к моей таблице, уже имеющих 87 столбцов и 53 миллиона записей. Затем я пытался обновить его в партиях

а> Время, затраченное на обновление 1000 записей >> 2.10 сек б> Время, необходимых для обновления 10000 записей >> 5.57 Секунды с> Времени, необходимой для обновления записей >> 1000000 5.42 минут d> Время, затраченное на обновление 53 миллионов записей >> 4. 5 часов (израсходовано табличное пространство, и нам нужно было расширить табличное пространство)

Может ли кто-нибудь предложить более быстрый способ обновления?

Answer 1

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

Может быть, это уместно записать данные в XML-документ, а затем сохранить документ в БД ...

Answer 2

Edit: Это на самом деле очень интересный вопрос, теперь мне очень интересно об этом. Я предлагаю сделать некоторые тесты реального мира, одну большую таблицу и множество таблиц, с максимально возможной информацией. Это может стоить дополнительных усилий! Помните, что даже реляционные БД могут зависать, если они разработаны плохо, и есть миллионы записей (я испытал это, когда был заключен контракт с андеррайтинговой компанией, нелегко исправить после факта). Таким образом, ваш дизайн с одним столом может также работать - доказательство в тестировании.

53 миллиона записей? Надеюсь, вы используете настоящий реляционный движок базы данных, такой как MySQL/SQL, который предназначен для обработки больших таблиц.

600+ Столбцы в одном столе звучат, как перебор, для меня. Я предполагаю, что это не единичная структура записей, поэтому вы выбираете подход «все в одном ряду»? Даже в этом случае лучше было бы иметь отдельные таблицы, в зависимости от ваших данных.

Answer 3

Вопросы вы должны спросить себя:

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

Answer 4

Вы могли бы рассмотреть вопрос об использовании базы данных столбца ориентированных, посмотри на HBase (http://hadoop.apache.org/hbase/), это распределенный, колонок-ориентированный магазин по образцу большого стола Google.

Answer 5

Без обид никого ... Интересно, действительно ли ваши данные, хранящиеся в 100 столбцах раз 53 миллиона записей, являются normalized?

Если нет, вы действительно должны начать делать это. Вы, вероятно, могли бы значительно сократить количество строк (например, его можно было бы разделить на три таблицы из 1000 и 1000 и 53 записей. Я знаю, что это не так просто, просто чтобы показать, насколько малы числа теоретически могут быть). Скорее всего, после нормализации все еще есть таблица с 53 миллионами записей, но это, можно надеяться, останется маленьким, оно может состоять только из внешних ключей. Обычно вам не нужны все данные одновременно. В идеале вы можете выполнять множество запросов на таблицах всего за несколько тысяч записей.

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