как я могу эффективно обрабатывать миллиард записей

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

CREATE TABLE `temp_content_closure2` (
  `parent_label` varchar(2000) DEFAULT NULL,
  `parent_code_id` bigint(20) NOT NULL,
  `parent_depth` bigint(20) NOT NULL DEFAULT '0',
  `content_id` bigint(20) unsigned NOT NULL DEFAULT '0',
  KEY `code_content` (`parent_code_id`,`content_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50100 PARTITION BY KEY (parent_depth)
PARTITIONS 20 */ |

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

+----------------+----------------+--------------+------------+
| parent_label   | parent_code_id | parent_depth | content_id |
+----------------+----------------+--------------+------------+
|  Taxonomy |          20000 |            0 |        447 |
| Taxonomy |          20000 |            0 |       2286 |
|  Taxonomy |          20000 |            0 |       3422 |
| Taxonomy |          20000 |            0 |       5916 |
+----------------+----------------+--------------+------------+

Здесь content_id будет уникальным по отношению к parent_dept, поэтому я использовал parent_depth в качестве ключа для разделения. На каждой глубине у меня есть 2577833 строки для обработки, поэтому здесь разделение бесполезно, я получил идею от веб-сайтов использовать механизм хранения архива. но он будет использовать полное сканирование таблицы и не использовать индекс при выборе, в основном 99% я использую запрос выбора в этой таблице, и эта таблица будет увеличивать свой счет каждый день. В настоящее время я нахожусь в базе данных mysql, которая имеет версию 5.0.1.i получил представление об использовании базы данных nosql, но есть ли способ справиться с mysql, если вы предлагаете средства nosql, которые я могу использовать cassandra или accumulo?.


mysql cassandra query-optimization accumulo
person kumar    schedule 27.09.2013    source источник
comment
у вас должен быть как минимум индекс для content_id   -  person FaddishWorm    schedule 27.09.2013
comment
@FaddishWorm, я добавил составной первичный ключ, это бесполезно :(   -  person kumar    schedule 27.09.2013

Ответы (2)


arrow_upward
0
arrow_downward

Добавьте такой индекс:

ALTER TABLE table ADD INDEX content_id ('content_id')

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

Множественные и одиночные индексы

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

Ознакомьтесь также с решениями для больших данных.

person FaddishWorm    schedule 27.09.2013

arrow_upward
0
arrow_downward

С таким размером и объемом данных вам нужно будет либо установить сегментированную установку MySQL в кластере машин (Facebook и Twitter хранят огромные объемы данных в сегментированной настройке MySQL, так что это возможно), либо, в качестве альтернативы, использовать Решение на основе больших таблиц, которое естественным образом распределяет данные между узлами в различных кластерах — Cassandra и HBase являются наиболее популярными альтернативами. Вы должны понимать, что миллиард записей на одной машине превысит почти все ограничения системы — сначала ввод-вывод, затем память, а затем ЦП. Это просто невыполнимо.

Если вы пойдете по пути Big Table, Cassandra будет быстрее всего настроить и протестировать. Однако, если вы ожидаете потребности в аналитике типа уменьшения карты, то HBase более тесно интегрирован с экосистемой Hadoop и должен работать хорошо. С точки зрения производительности, они оба ноздря в ноздрю, так что выбирайте сами.

person Nikhil    schedule 27.09.2013
comment
Привет, Нихил, спасибо за повтор, кстати, я проверил кассандру, я задавался вопросом о ее производительности: 1000 записей в секунду вставляются в семейство столбцов, но я не могу выполнять агрегацию, в основном я обрабатываю аудит событий, поэтому мне нужно группировать по и использовать сумму или счет в данных. Для этой кассандры не было группы по функции суммы. Я не знаю о HBase, пожалуйста, скажите, возможна ли эта агрегация в HBase, если нет, как я могу справиться с этим? - person kumar; 27.09.2013
comment
В Cassandra вам придется выполнять любую агрегацию/группировку/фильтрацию на стороне приложения. Cassandra имеет клиентскую поддержку для нескольких языков (wiki.apache.org/cassandra/ClientOptions‎), так что вы можете легко интегрировать свою логику в выбранный язык и достичь даже большего, чем с помощью SQL. HBase имеет аналогичные ограничения, но предлагает привлекательный вариант в виде Phoenix (github.com/forcedotcom/phoenix), который фактически дает вам очень знакомый SQL-подобный уровень над вашим кластером HBase с поддержкой многих расширенных операций. - person Nikhil; 28.09.2013