Pull to refresh

Методы оптимизации производительности приложения при работе с РБД

Reading time 3 min
Views 7.4K
Действуют они везде – хоть MySQL, хоть Oracle хоть самописная БД. Чем умнее БД – тем больше она старается оптимизировать сама, но лучше ей помочь

1. Разделяй и властвуй, а попросту кластеризация БД – все данные одного типа можно еще разбить на кластеры – отдельные таблицы, в каждую таблицу попадают записи, которые удовлетворяют какому-то простейшему правилу, например в таблицу с индексом I попадают данные у которых ID%N==I, где N – кол-во кластеров. Таким образом очень просто и эффективно делим те данные, которые не надо считывать последовательно – например разбиваем все слова на 100-200-миллион блоков, в каждом блоке только слова у которых ID%N==I. В качестве примера в большой системе, типа социальной сети, можно поделить все данные по признаку принадлежности одному пользователю — например все фото разместить в N таблиц, информация о фото помещается в таблицу K=USER_ID%N

2. Условно — работа с диском. Всегда пиши (вставляй) последовательно, кэшируй и буферизуй запись, читать старайся подряд от начала до конца. Ускорение записи может быть просто фантастическое – много порядков, просто от того что Вы правильно используете запись зная как работает Ваш (или производителя) алгоритм записи на диск. Данные почти всегда можно отсортировать до записи – в памяти ли, разные файлы ли с кускам текста – всегда можно построить индекс или простейший массив, который отсортирован по ID данных и читать-писать их в порядке как в индексе. Как один из вариантов – всегда можно придумать более оптимальную структуру хранения данных. К примеру когда надо вставить кусок таблицы в другую таблицу делать это лучше последовательно от меньшего ID к большему, заодно отключив механизм индексации. И включив его после вставки.

3. Не храните на диске то, что нужно часто – загрузите в память. Сейчас легко можно положить в память гигабайт, а то и два. Если все не помещается – разбейте данные на куски и делайте работу в рамках одного куска. Никакой memcached и аналоги не помогут в такой задаче, только Вы знаете, в какой последовательности данные попадут в обработку, поэтому сможете написать решение в десятки раз быстрее стандартных утилит. Для использования данных хорошо подходят многие «старые» структуры.
— хеширование (все данные разбиваются на части в соответствии с некоторым правилом, например CRC%N)
— AVL и B деревья (очень советую для себя любимого взять бумагу, ручку, C/C++ и реализовать их самостоятельно следуя только определениям, не читая алгоритма — разработать самому. Развивает смекалку и поднимает Ваш общий уровень)
— Heap с упорядоченной выборкой

4. Используйте указатели и связанные структуры. Пример из социальных сетей: часто из 100 млн фото сложно найти те, на которых отмечен конкретный человек, зато в информации о самом человеке легко хранить список таких фото. Аналогично: хранить в памяти все ссылки на страницы, которые есть в поиске, невозможно, зато легко помещаются url корня сайта. Вычислив по полной ссылке CRC или ID корня (любым образом) можно быстро найти место в файле где записаны все известные ссылки на этом сайте и проверить существует ли данная.

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

И еще: я придерживаюсь мнения что в любой задаче есть что оптимизировать, и если это критично — занимайтесь оптимизацией, и, заодно, собственным образованием по этой теме.

Полное содержание и список моих статей по поисковой машине будет обновлятся вот здесь: http://habrahabr.ru/blogs/search_engines/123671/
Tags:
Hubs:
+5
Comments 20
Comments Comments 20

Articles