Легко фильтруемая таблица базы данных с большим количеством записей - PullRequest
Новая
       35

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

0 голосов
/ 13 июня 2011

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

Таблица в настоящее время находится в базе данных MySQL со следующей структурой: 

CREATE TABLE `log_issues` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `id_user` int(11) DEFAULT NULL,
  `type` varchar(50) NOT NULL,
  `title` varchar(100) NOT NULL DEFAULT '',
  `message` mediumtext NOT NULL,
  `debug` mediumtext,
  `duration` float DEFAULT NULL,
  `date` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `date` (`date`,`title`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

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

Думаю, мне лучше использовать MongoDB или другую базу данных NoSQL, но у меня нет с ними никакого опыта. У базы данных на основе документов легче фильтровать большой набор данных без индексов, или я всегда буду сталкиваться с этой проблемой, независимо от базы данных?

Подведем итог:

У меня есть таблица с большим количеством данных, индексы не могут быть использованы (по крайней мере, если они должны быть упорядочены), и мне нужно получить результаты, не дожидаясь более 10 секунд. Какие технологии я могу использовать?

Любые предложения будут высоко оценены.

Ответы [ 3 ]

1 голос
/ 13 июня 2011

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

1 голос
/ 13 июня 2011

Сначала вы должны решить, хотите ли вы остаться на земле СУРБД или нет. В настоящее время это не имеет особого смысла для большинства сценариев, особенно со сложной структурой данных или требованием масштабирования.

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

Индексы требуются везде, в том числе и в любом NoSQL. Реальный вопрос в том, насколько легко их создавать и поддерживать. С RavenDB вы получаете индексацию без помощи рук; Индексы создаются автоматически по мере продвижения, в зависимости от типа запросов, которые вы делаете. Рекомендуется предварительно определить их, чтобы уменьшить устаревание, но все же они являются такими же индексами, когда они создаются автоматически.

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

1 голос
/ 13 июня 2011

Во-первых, что такое "навсегда"? Как долго мы здесь разговариваем?

Второй запуск индексации. Я знаю, что вы можете искать по любому полю, но что не так с 8 индексами?

Если у вас нет индекса, он выполнит сканирование таблицы, чтобы найти информацию, и это будет медленно.

Кроме того, если вы постоянно выполняете поиск в одном поле, вы можете рассмотреть возможность создания кластерного индекса в этом поле.

EDIT

Другой вариант, сохранить таблицу журналов как есть. Затем создайте несколько рабочих мест (ежечасно?), Которые будут организовывать ваши данные. Например, у нас есть таблица EventLog. Мы только когда-либо вставляем в эту таблицу. Затем у нас есть EventsByDate, EventsByHour, EventsByAccountId и т. Д. В виде отдельных таблиц. Затем они индексируются, и мы нажимаем на них, чтобы посмотреть на данные.

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

...