Очень широкие денормализованные данные (около 40000 столбцов). Какую базу данных использовать?

У меня очень специфическая проблема. У меня есть данные около 40000 столбцов. Данные денормализованы, потому что обработка в реальном времени заняла бы много времени.

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

Или, если не база данных, то способ хранения очень широких данных?

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

Спасибо!

Редактировать:

census.gov/programs-surveys/acs/data.html Это набор данных. Пример таблицы:

номер людей на какой-то улице:

Столбцы: количество людей, количество людей в возрасте ‹18 лет, количество людей в возрасте ‹22 лет, количество людей в возрасте 22‹30 лет и т. д.

И эти комбинации становятся все выше и выше. Включите расу, пол, национальность и т. д. Вот ваши 40000 столбцов. И эти столбцы не могут быть рассчитаны на лету. Его нужно предварительно вычислить и сохранить для более быстрого чтения — Форсайт 15 минут назад


postgresql database denormalization
person Forsythe    schedule 30.03.2016    source источник
comment
Мне очень любопытно, как добавление строк с 40000 столбцов может быть быстрее, чем нормализованные данные с использованием правильных соединений и запросов SQL?   -  person Martin Verjans    schedule 30.03.2016
comment
Какова цель таблицы? Выбирает? Вставки? Обновления? Какая информация? Вы уже пытались оптимизировать свои запросы?   -  person PeeHaa    schedule 30.03.2016
comment
Вы действительно уверены, что все 40 тыс. столбцов должны принадлежать одной таблице?   -  person Jakub Kania    schedule 30.03.2016
comment
40000 столбцов? шутки в сторону? Очень интересно узнать, что представляют собой эти данные. Это должно дать подсказку, где что-то идет не так.   -  person Amit Sukralia    schedule 30.03.2016
comment
@Martin Потому что данные столбца генерируются на основе некоторых формул. Запуск этих формул для создания нового столбца занял бы много времени. Таким образом, данные предварительно вычисляются и помещаются в таблицу, чтобы их можно было быстро получить.   -  person Forsythe    schedule 30.03.2016
comment
@JakubKania Да, я уверен.   -  person Forsythe    schedule 30.03.2016
comment
@PeeHaa В основном выбирает. Запрос не проблема. Проблема в том, что мне нужен эффективный способ хранения данных с 40000 столбцов в базе данных без разделения данных на более мелкие таблицы, а затем объединения их по запросу.   -  person Forsythe    schedule 30.03.2016
comment
Используйте столбец hstore (хранилище ключей/значений)   -  person a_horse_with_no_name    schedule 30.03.2016
comment
Ну, я не знаю, как это обойти, ограничение столбца - это то, что вы не можете сломать... Итак, если бы вы могли привести пример, мы могли бы лучше понять и предоставить вам старт для решения   -  person Martin Verjans    schedule 30.03.2016
comment
census.gov/programs-surveys/acs/data.html Это это набор данных. Таблица: №. количество людей на какой-либо улице: Столбцы: количество людей, количество людей в возрасте ‹18, количество людей в возрасте ‹22, количество людей в возрасте 22‹30 лет и т. д. И эти комбинации становятся все выше и выше. Включите расу, пол, национальность и т. д. Вот ваши 40000 столбцов. И эти столбцы не могут быть рассчитаны на лету. Его необходимо предварительно рассчитать и сохранить для более быстрого чтения.   -  person Forsythe    schedule 30.03.2016
comment
Итак, ваша проблема действительно в том, что вы не можете написать правильный динамический запрос для запроса нескольких таблиц? Не втискивайте так много столбцов в одну таблицу только потому, что написание SELECT было грязным, вам лучше обойтись без СУБД, если вы просто хотите рассматривать ее как одну большую таблицу.   -  person Jakub Kania    schedule 30.03.2016
comment
@JakubKania, поэтому я публикую этот вопрос. Как лучше всего хранить такую ​​таблицу. Посмотрите на мой комментарий выше.   -  person Forsythe    schedule 30.03.2016
comment
Я не понимаю, почему вы не можете правильно нормализовать эти данные?   -  person a_horse_with_no_name    schedule 30.03.2016
comment
@a_horse_with_no_name Нормализация даст мне больше таблиц. Я не хочу больше столов. У меня есть одна таблица, которую я хочу сохранить. Должен быть способ сделать это (не обязательно Postgres)   -  person Forsythe    schedule 30.03.2016
comment
как запомнить название каждого столбца? Это не имеет значения, что вы не можете программно получить ни один столбец. Каждый раз, когда я вижу, как кто-то использует инструкции, которые простейшая база данных, такая как SQLite, не может принять, я думаю, что он очень-очень неправильно структурирует свою базу данных. Специальные инструкции полезны с рекурсивными наборами данных или специальными данными, где SQLite не может ничего сделать, если вы не хотите вставлять их самостоятельно. Но анаграфический набор данных — это первый пример, сделанный в первый час урока SQL. Это должно быть сделано с помощью RDBMS   -  person jurhas    schedule 30.03.2016
comment
Почему бы не использовать пары ключ-›значение? Улица — это одна улица в одной таблице, а все столбцы в вашем наборе данных (возраст‹22, возраст‹24 и т. д.) в виде отдельной таблицы с ключом и значением столбца, указывающим на улицу? Или, что еще лучше, таблицы Street и Keys, а затем значения таблицы M-M, которые их соединяют. Затем вы можете повторно использовать и искать очень легко. Простой и легкий, требует минимального количества таблиц и не ломает PostgreSQL.   -  person Dytut    schedule 30.03.2016

Ответы (2)


arrow_upward
3
arrow_downward

Это слишком долго для комментария.

Все базы данных, которые я могу легко представить, имеют ограничения в несколько тысяч (по крайней мере, SQL Server, MS Access, Oracle, MySQL, Postgres, Teradata и DB2). Возможно, вам повезет больше со столбцовыми базами данных, но они довольно специализированы.

Это оставляет вам различные варианты:

  • Вы можете использовать пары ключ-значение для данных. Однако, если данные плотные, у вас могут быть очень большие данные.
  • Вы можете использовать другие структуры данных, такие как JSON, XML, массивы (в Postgres) или BLOB (двоичные большие объекты).
  • Вы можете использовать технологии NOSQL для хранения данных.
  • Вы можете использовать инструменты статистики, такие как R, SAS и SPSS.

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

person Gordon Linoff    schedule 30.03.2016
comment
Кроме того, можно сгруппировать столбцы в несколько таблиц и соответствующим образом соединить их. Я бы предположил, что не всем запросам потребуются все 40 000 столбцов. Это также поможет лучше кэшировать горячие данные. - person vyegorov; 30.03.2016
comment
В Postgres я бы, вероятно, использовал для этого hstore. - person a_horse_with_no_name; 30.03.2016
comment
Данные в основном будут использоваться для чтения, но с очень специфическими ограничениями. Например, мне потребуется запустить функцию для столбцов 1, 56, 10000 и 29999. Или даже запустить подзапрос. Но для запуска этой функции (или подзапроса) мне нужно было бы правильно хранить эту таблицу. Postgres в настоящее время вызывает у меня головную боль. Потому что мне нужно разбить эту большую таблицу на более мелкие, а затем объединить их по какому-то запросу (пользователь все еще видит большую таблицу). Например. пользователь отправляет запрос для большой таблицы, я должен проанализировать ее и получить данные из всех фрагментов таблицы. - person Forsythe; 30.03.2016

arrow_upward
0
arrow_downward

Может быть, я ошибаюсь, но здесь, похоже, проблема с пониманием и сортировкой данных...

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

НАСТОЯЩИЕ данные здесь - это возраст всех, их пол... Затем все остальные столбцы просто вычисляются...

Затем ваш запрос необходимо параметризовать, чтобы вы могли правильно выбрать.

Пример использования PHP и MySQL:

//These vars come from user input
$ageMin = 18;
$ageMax = 21;
$gender = "male";

$query = "SELECT COUNT(*) FROM MyTable WHERE 
          Age >= {$ageMin} AND
          Age <= {$ageMax} AND
          Gender = '{$gender}' ... "

И если вы говорите, что это невозможно предварительно вычислить, сохраните эти результаты в таблице в виде строк:

Table Calculated
  IDCalculation (INTEGER)
  Name (CHAR(30))
  Criteria
  Result

Итак, вы просто преобразуете свои 40000 столбцов в строки.

person Martin Verjans    schedule 30.03.2016