Может ли MySQL разумно выполнять запросы на миллиарды строк?

Я планирую хранить сканирование с масс-спектрометра в базе данных MySQL и хотел бы знать, является ли хранение и анализ этого объема данных удаленно возможно. Я знаю, что производительность сильно зависит от среды, но я ищет приблизительный порядок: запросы будут занимать 5 дней или 5 миллисекунды?

Формат ввода

Каждый входной файл содержит один прогон спектрометра; каждый пробег набора сканирований, и каждое сканирование имеет упорядоченный массив данных. Eсть бит метаданных, но большая часть файла состоит из массивов 32- или 64-битные int или float.

Хост-система

| ---------------- + ------------------------------- |
| ОС | Windows 2008 64-бит |
| Версия MySQL | 5.5.24 (x86_64) |
| Процессор | 2x Xeon E5420 (всего 8 ядер) |
| ОЗУ | 8GB |
| SSD файловая система | 500 ГБ |
| HDD RAID | 12 TiB |
| ---------------- + ------------------------------- |

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

Статистика файлов

| ------------------ + -------------- |
| количество файлов | ~ 16 000 |
| общий размер | 1,3 TiB |
| минимальный размер | 0 байт |
| максимальный размер | 12 GiB |
| средний | 800 MiB |
| медиана | 500 MiB |
| общие данные | ~ 200 миллиардов |
| ------------------ + -------------- |

Общее число точек данных является приблизительной оценкой very .

Предлагаемая схема

Я планирую делать «правильно» (т. е. нормализовать данные как сумасшедшие) и поэтому будет иметь таблицу runs, таблицу spectra с внешним ключом для runs, и datapoints с внешним ключом в spectra.

200-битный вопрос с датой использования

Я собираюсь анализировать несколько спектров и, возможно, даже несколько запускается, что приводит к запросам, которые могут касаться миллионов строк. Предполагая, что индекс I все правильно (что является темой для другого вопроса), и я не пытаюсь shuffle сотни MiB по всей сети, это удалённо правдоподобно для MySQL для этого?

Дополнительная информация

Данные сканирования будут поступать из файлов на основе XML mzML . Мясо этого формата находится в <binaryDataArrayList>, где хранятся данные. Каждое сканирование производит> = 2 <binaryDataArray>, которые вместе взятые образуют 2-мерную (или больше) массив формы [[123.456, 234.567, ...], ...].

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

Мой план наивысшей схемы базы данных:

runs таблица

| имя столбца | тип |
| ------------- + ------------- |
| id | ПЕРВИЧНЫЙ КЛЮЧ |
| start_time | TIMESTAMP |
| имя | VARCHAR |
| ------------- + ------------- |

spectra таблица

| имя столбца | тип |
| ---------------- + ------------- |
| id | ПЕРВИЧНЫЙ КЛЮЧ |
| имя | VARCHAR |
| индекс | INT |
| spectrum_type | INT |
| представительство | INT |
| run_id | ИНОСТРАННЫЙ КЛЮЧ |
| ---------------- + ------------- |

datapoints таблица

| имя столбца | тип |
| ------------- + ------------- |
| id | ПЕРВИЧНЫЙ КЛЮЧ |
| spectrum_id | ИНОСТРАННЫЙ КЛЮЧ |
| mz | DOUBLE |
| num_counts | DOUBLE |
| индекс | INT |
| ------------- + ------------- |

Является ли это разумным?


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

Вот график одного спектра (сканирования) того типа данных, с которым я буду дело:

Скриншот Viewer

Цель программного обеспечения - выяснить, где и насколько значительны пики находятся. Мы используем проприетарный пакет программного обеспечения, чтобы понять это сейчас, но мы хотим написать собственную программу анализа (в R), чтобы мы знали, что происходит под простынями. Как вы можете видеть, подавляющее большинство данных неинтересный, но мы не хотим выбрасывать потенциально полезные данные, которые алгоритм пропущен. Когда у нас есть список вероятных пиков, с которыми мы удовлетворены, остальная часть трубопровода будет использовать этот пиковый список, а не сырой список данных. Я полагаю, что было бы достаточно сохранить сырье datapoints как большой капля, поэтому они могут быть переанализированы, если необходимо, но сохраняйте только пики как отдельные записи базы данных. В этом случае будет только пара дюжины пиков по спектру, поэтому сумасшедший скейлинг не должен бытьстолько проблемы.

263 голоса | спросил haxney 2 J000000Monday12 2012, 23:36:13

15 ответов


106

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

Как правило, хранение двоичных данных в базах данных является ошибкой большую часть времени. Как правило, лучший способ решения проблемы. Хотя из-за неправильного хранения двоичных данных в реляционной базе данных часто недостатки перевешивают выгоды. Реляционные базы данных, как указано в названии, лучше всего подходят для хранения реляционных данных. Двоичные данные не являются реляционными. Он добавляет размер (часто значительно) к базам данных, может повредить производительность и может привести к возникновению вопросов об обслуживании экземпляров MySQL с миллиардом записей. Хорошей новостью является то, что существуют базы данных, особенно хорошо подходящие для хранения двоичных данных. Одна из них, хотя и не всегда легко очевидна, - это ваша файловая система! Просто придумайте структуру именования каталогов и файлов для ваших двоичных файлов, храните их в своей базе данных MySQL вместе с любыми другими данными, которые могут давать значение через запрос.

Другим подходом будет использование системы хранения на основе документов для данных datapoints (и, возможно, спектров), а также использование MySQL для прогонов (или, возможно, включение пробегов в один и тот же БД, как и другие).

ответил Krystian Cybulski 3 J000000Tuesday12 2012, 19:57:43
105

Я работал с очень большой (Terabyte +) базой MySQL. Самая большая таблица у нас была буквально более миллиарда строк. Это использовало MySQL 5.0, поэтому возможно, что ситуация может быть улучшена.

Это сработало. MySQL обрабатывал данные правильно большую часть времени. Это было очень громоздко. (Если вы хотите наличие на шесть уровней сигма с терабайтом данных, не используйте MySQL. Мы были стартапом, у которого не было DBA и ограниченных средств.)

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

У нас было множество таблиц в диапазоне 10-100 миллионов рядов. Любое значительное присоединение к таблицам было слишком трудоемким и длилось бы вечно. Таким образом, мы написали хранимые процедуры, чтобы «ходить» по таблицам и обрабатывать соединения с диапазонами «id». Таким образом мы обрабатывали данные по 10-100 000 строк за раз (присоединяются к идентификаторам 1-100,000, затем 100,001-200,000 и т. Д.). Это было значительно быстрее, чем соединение со всей таблицей.

Использование индексов на очень больших таблицах, которые не основаны на первичном ключе, также намного сложнее. Mysql 5.0 хранит индексы в двух частях - он хранит индексы (кроме первичного индекса) в качестве индексов для значений первичного ключа. Таким образом, индексированные поисковые запросы выполняются в двух частях: первый MySQL переходит к индексу и извлекает из него значения первичного ключа, которые ему нужно найти, затем он выполняет второй поиск индекса первичного ключа, чтобы найти, где эти значения.

В сетке этого показателя для очень больших таблиц (1-200 млн. строк) индексирование таблиц является более ограничительным. Вам нужно меньше простых индексов. И даже простые утверждения select, которые не относятся непосредственно к индексу, никогда не возвращаются. Где clures должен набирать индексы или забывать об этом.

Но все, что было сказано, действительно работало. Мы смогли использовать MySQL с этими очень большими таблицами и выполнять вычисления и получать правильные ответы.

Попытка провести анализ на 200 миллиардов рядов данных потребует очень высокого уровня аппаратного обеспечения и много рук и терпения. Просто сохранение резервных копий данных в формате, который вы могли бы восстановить, будет значительной работой.

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

Все, что у нас было, это InnoDB. Что касается MyISAM против InnoDB: главное было бы не смешивать их. Вы не можете оптимизировать сервер для обоих из-за того, как MySQL кэширует ключи и другие данные. Выберите один или другой для всех таблиц на сервере, если сможете. MyISAM может помочь с некоторыми проблемами с быстродействием, но это может не помочь с общей работой DBA, которая должна быть выполнена - что может быть убийцей.

ответил Kevin Bedell 2 J000000Monday12 2012, 23:48:44
69
  

нормализует данные как сумасшедшие

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

Is this reasonable?

Я бы также создал дополнительную плоскую таблицу со всеми данными.

run_id | spectrum_id | data_id | <data table columns..> |

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

Стратегия - это запрос в вышеприведенной таблице, дамп результатов в таблицу temp и присоединение к таблице temp с таблицами поиска Run и Spectrum и получение требуемых данных.


Проанализировали ли вы свои потребности в потребностях против потребностей чтения? Будет очень заманчиво перерезать SQL и перейти к нестандартным механизмам хранения данных. На мой взгляд, это должно быть последним средством.

Чтобы ускорить скорость записи, вы можете попробовать использовать метод Handler Socket. Percona, если я помню, пакеты Handler Socket в их установочном пакете. (нет отношения к Percona!)

http://yoshinorimatsunobu.blogspot.com/2010/10 /using-mysql-as-nosql-story-for.html

ответил srini.venigalla 3 J000000Tuesday12 2012, 00:00:01
32

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

Насколько вы нормализуете свои данные, зависит от операций, которые вы планируете выполнять с сохраненными данными. Ваша таблица «datapoints», в частности, кажется проблематичной - планируете ли вы сравнить n-ю точку от любых заданных спектров с m-м любого другого? Если нет, сохранение их отдельно может быть ошибкой. Если ваши точки данных не одиноки, а имеют смысл только в контексте связанных с ними спектров, вам не нужен ПЕРВЫЙ КЛЮЧ - внешний ключ для спектров и столбец «nth» (колонка «index»?) Будет достаточным .

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

Самый большой MySQL, с которым я когда-либо лично управлял, составлял ~ 100 миллионов строк. При таком размере вы хотите сохранить свои строки и, таким образом, ваши поля фиксированным размером - это позволяет MySQL для эффективного расчета позиции любой строки в таблице путем умножения на фиксированный размер каждой строки (думаю, указатель арифметики) - хотя точные детали зависят от того, какой механизм хранения вы планируете использовать. Используйте MyISAM, если вы можете с ним справиться, чего не хватает в надежности, которую он компенсирует скоростью, и в вашей ситуации этого должно быть достаточно. Замените поля переменной размера, такие как VARCHAR на CHAR (n), и используйте RTRIM () для ваших запросов на чтение.

После того, как строки таблицы будут фиксированной шириной, вы можете уменьшить количество байтов, тщательно оценив MySQL целочисленные типы данных (некоторые из них являются нестандартными). Каждая 1-байтная экономия, которую вы можете извлечь, конвертируя 4-байтовый INT в 3-байтный MEDIUMINT, экономит ~ 1 Мбайт на миллион строк - это означает меньше дискового ввода-вывода и более эффективного кэширования. Используйте наименьшие возможные типы данных, с которыми вы можете избавиться . Тщательно оцените типы с плавающей запятой и посмотрите, можете ли вы заменить 8-байтовые DOUBLE на 4-байтовые FLOAT или даже <8 байт NUMERICs с фиксированной точкой . Запустите тесты, чтобы убедиться, что все, что вы выбираете, не укусит вас позже.

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

Самое главное, что бы вы ни делали, не предполагайте, что вы выбрали идеальную схему, а затем слепо начинаете сбрасывать 10 миллионов миллионов записей. Хорошие проекты требуют времени для развития. Создайте большой, но управляемый (скажем, 1-5%) набор тестовых данных и проверьте правильность и производительность вашей схемы. Посмотрите, как работают разные операции (http://dev.mysql.com/doc/refman/5.0/en/using-explain.html) и убедитесь, что вы балансируете схему в пользу наиболее частых операций.

Я сказал коротко? Упс. В любом случае, удачи!

ответил Ryan Flynn 3 J000000Tuesday12 2012, 18:34:31
22

Казалось бы, единственная причина для измельчения данных точек данных из XML (в отличие от метаданных, таких как время и тип запуска) и в форме базы данных, - это когда вы анализируете спектры по массивам, т. е. возможно, найдя все прогоны с определенной подписью. Только сейчас вы знаете свой проблемный домен, но это может быть сродни хранению музыки, отснятой на частоте 96 кГц, с 1 образцом на строку. Я не уверен, что размер больше, чем использование данных. Запрос по данным будет эквивалентен заданию относительной амплитуды 2 минуты в песне во всех песнях The Beatles. Если вы знаете, какие анализы могут быть выполнены, вполне возможно, что выполнение этих сигналов и сохранение их в метаданных о запуске может иметь больше смысла.

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

Итак, как и многие вопросы, прежде чем спрашивать о том, как MySQL обрабатывает вашу модель, отступать назад и смотреть на модель и как она будет использоваться, вероятно, более уместна, чем беспокоиться о производительности пока.


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

ответил Cade Roux 3 J000000Tuesday12 2012, 22:29:19
17

Я запускаю службу веб-аналитики с примерно 50 серверами баз данных, каждая из которых содержит много таблиц более 100 миллионов строк, а несколько из них имеют более миллиарда строк, иногда до двух миллиардов (на каждом сервере).

Производительность здесь прекрасна. Это очень нормализованные данные. Тем не менее - моя основная забота в том, чтобы прочитать это, что вы будете намного старше отметку в 4,2 миллиарда строк для этих таблиц (может быть, не «работает», а, вероятно, и две другие), а это значит, что вам нужно использовать BIGINT вместо INT для первичные /внешние ключи.

Производительность MySQL с полями BIGINT в индексированном столбце смехотворно ужасно по сравнению с INT. Я сделал ошибку, сделав это один раз со столом, который, как я думал, может расти над этим размером, и как только он ударил несколько сотен миллионов строк, производительность была просто ужасной. У меня нет сырых чисел, но когда я говорю «плохо», я имею в виду Windows ME плохо.

Этот столбец был основным ключом. Мы преобразовали его обратно как INT и presto magico, производительность была хорошей снова.

Все наши серверы в то время находились на Debian 5 и с MySQL 5.0. С тех пор мы обновили до Debian 6 и Percona MySQL 5.5, поэтому с тех пор ситуация улучшилась. Но, основываясь на моем опыте, нет, я не думаю, что он будет работать очень хорошо.

ответил Sean 4 J000000Wednesday12 2012, 00:30:56
16

Независимо от того, работает ли это, вы всегда сталкиваетесь с одной проблемой с одним монолитным носителем: диски медленны. При скорости 100 Мбайт /с (довольно неплохо для прядильных носителей) требуется всего 3 часа, чтобы прочитать таблицу 1 ТБ; это предполагает, что анализ или поиск или другие задержки не замедлят вас.

Вот почему почти каждая установка «больших данных» использует какое-то распределенное хранилище данных. Вы можете потратить в 8 раз больше денег на создание одного супер удивительного компьютера для запуска вашей БД, но если у вас есть много данных, которые можно сканировать параллельно, вы почти всегда лучше распределяете нагрузку на 8 более дешевых компьютеров.

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

ответил tylerl 4 J000000Wednesday12 2012, 07:17:39
12

Hm ... Я вижу две причины, по которым вы выбрали такую ​​структуру данных:

  • вам действительно нужно сделать какой-либо datapoint vs любые запросы к данным datapoint
  • вы намерены выполнить всю свою логику в SQL

Теперь я бы предложил внимательно изучить ваши требования и убедиться, что хотя бы одно из приведенных выше допущений верно. Если ни один из них не верен, вы просто делаете что-то медленнее. Для такого набора данных я бы предложил сначала узнать, как ожидается доступ к данным, какая точность вам понадобится и т. Д., А затем спроектируйте свою базу данных вокруг них.

P.S .: Имейте в виду, что вам понадобится по крайней мере 36 + 5 байт на каждую точку данных, поэтому с 200-битными точками, которые должны предоставить вам не менее 8,2 ТБ требуемого пространства.

PPS: вам не нужен столбец id в таблице datapoints, вероятно, достаточно кода PRIMARY KEY (spectrum_id, index) просто будьте осторожны, что index может быть зарезервированным словом)

ответил 3 J000000Tuesday12 2012, 20:56:36
11

EDIT:

НЕ ДЕЛАЙТЕ ЭТО В MYSQL С ДАННЫМИ, ЗАПОМНЕННЫМИ НА ОДНОМ ДИСКЕ. Просто чтение этого объема данных с одного носителя займет несколько часов. Вам нужно ПРОСМОТРЕТЬ, НЕ ВВЕРХ.

И вы должны денормализовать свои данные, если хотите провести эффективный анализ данных. Вы не разрабатываете онлайн-систему здесь. Вы хотите, чтобы хруст числа, дизайн соответственно.

Оригинальный ответ ниже строки.


Ответ будет зависеть от ваших запросов, MySQL не может быть лучшим инструментом для этой работы. Вы можете взглянуть на решение, которое вы можете масштабировать «вне», а не «вверх». Если вы готовы приложить некоторые усилия, возможно, вам стоит взглянуть на решение «Уменьшить карту», ​​например, Hadoop.

Если вы хотите сделать больше специальных запросов решение BigQuery от Google, это может пригодиться вам. Соответствующая презентация от Google I /O 2012: Хрустание больших данных с помощью BigQuery

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

ответил mdolk 3 J000000Tuesday12 2012, 21:39:42
8

Никто не упомянул, поэтому мое предложение. Взгляните на массивные MySQL решения. Например, см. Этот высоко оцененный презентация tumblr .

Концепция такова:

  • Вместо одной дополнительной большой базы данных
  • Используйте многие небольшие, содержащие части исходных данных.

Таким образом, вы можете масштабировать горизонтально, а не пытаться улучшить вертикальную производительность. Google BigTable и GFS также используют дешевые горизонтально масштабируемые узлы для хранения и запроса петабайт данных .

Однако возникнут проблемы, если вам нужно запускать запросы по различным осколкам.


Если кто-то заинтересован, я сделал приложение для привязки к приветствующему миру некоторое время назад. Об этом говорится в здесь в сообщении в блоге. Я использовал RavenDB и C #, но детали неактуальны, и идея одна и та же.
ответил oleksii 4 J000000Wednesday12 2012, 03:53:56
6

На какой машине будут храниться данные? Это общие устройства хранения данных?

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

Скорость чтения /записи жесткого диска будет в 200-300 раз медленнее, чем скорость памяти. Ищите жесткие диски с очень быстрой задержкой и скоростью чтения и записи. Если все эти данные находятся на одном двухцилиндровом диске, вы, вероятно, будете ждать долгое время для завершения запросов. Задержка жесткого диска составляет ~ 10-15 миллисекунд, а латентность памяти меньше 10nanoseconds. Задержка жесткого диска может быть на 1000-2000x медленнее, чем латентность памяти. Движение механического рычага на жестком диске является наименьшей вещью во всей этой системе.

Сколько у вас RAM? 16 гигабайт? Допустим, это позволяет вам хранить 32 записи. У вас 16000 файлов. Если вы собираетесь линейно сканировать все точки данных, вы можете легко получить 5-10 секунд в режиме поиска. Затем коэффициент скорости передачи 50 мб /с? Около 7 часов. Кроме того, любые временно сохраненные данные должны быть сохранены на жестком диске, чтобы освободить место для считывания новых данных.

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

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

Оптимизация запросов может обрабатывать только один запрос за раз. Поэтому вложенные операторы select не могут быть оптимизированы. ОДНАКО, если вы знаете, что определенный вложенный запрос приведет к тому, что небольшой набор данных будет возвращен, сохраните его. Оптимизация запросов использует гистограммы и грубые допущения, если вы знаете что-то о данных и запросе, тогда идите и делайте это.

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

Если вы собираетесь изменять значения имени (varchars), я бы изменил его на тип данных с максимальным размером, это предотвратит фрагментацию и компромисс - это всего лишь несколько байт памяти. Возможно, NVARCHAR со 100 максимумами.

Что касается комментариев о денормализации таблицы. Я думаю, что лучше всего хранить данные в больших группах (возможно, в виде спектров), а затем выполнять анализ данных на языке python или на языке, который взаимодействует с базой данных. Если у вас нет SQL-Wizard.

ответил JustinDanielson 3 J000000Tuesday12 2012, 21:22:20
5

Для меня это звучит как сценарий использования, где вы хотите что-то вроде «хранилища реляционных столбцов» , как описано здесь .

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

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

Я действительно могу неправильно понять проблему, и я даже не предлагаю конкретного решения.

Вот еще один разговор , который может быть уместным, даже если он не является действительно текущее или развертываемое решение.

ответил RandallZ 4 J000000Wednesday12 2012, 00:44:31
5

Я бы порекомендовал вам попробовать разбить таблицу. У нас есть более 80 миллионов строк в одном столе (данные на фондовом рынке) и не имеют проблем с ним быстро.

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

http://dev.mysql.com/doc/RefMan /5,1 /а /секционирования-limitations.html

http://www.slideshare.net/datacharmer/mysql-partitions-tutorial

ответил user9866 4 J000000Wednesday12 2012, 03:51:46
4

Да, но ...

Я работал с таблицами, имеющими 2 миллиарда строк. Однако ожидалось, что только запросы с использованием ПК будут быстрыми.

Самое главное, что у аппаратного обеспечения было достаточно ОЗУ для размещения целых таблиц в памяти. Когда это стало проблемой (доведено до 96 ГБ в то время), пошел на вертикальное разбиение, сохраняя размер таблицы на каждой машине, достаточно малой, чтобы по-прежнему вписываться в память. Кроме того, машины были подключены через 10Gb-волокно, поэтому пропускная способность сети не была такой большой проблемой.

BTW. ваша схема выглядит как что-то, что может вписаться в решение NoSQL, используя run_id как хэширующий ключ для спектров и spectrum_id как хэширующий ключ для точек данных.

ответил vartec 4 J000000Wednesday12 2012, 14:07:02
3

Я писал об этой теме в своем блоге: http: //www .tocker.ca /2013/10/24 /улучшения-на-производительность из-больших столов-в-MySQL.html

Чтобы повторить некоторые ключевые моменты:

  • B-деревья ухудшаются по мере их увеличения и не вписываются в память (MySQL здесь не один).
  • У InnoDB есть некоторые функции, которые помогают поддерживать некоторую производительность (изменение буферизации, ранее называемое «вставным буфером»).
  • Разделение также может помочь.

В комментариях моего сообщения Тим Каллаган связан с этим: http://www.tokutek.com/resources/эталонные-результаты /реперов-против-InnoDB-винчестеры /# iiBench

Что показывает вставку 1 миллиарда строк с использованием теста iibench.

ответил Morgan Tocker 5 ThuEurope/Moscow2013-12-05T01:54:56+04:00Europe/Moscow12bEurope/MoscowThu, 05 Dec 2013 01:54:56 +0400 2013, 01:54:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132