Улучшение производительности запросов таблицы базы данных с большим количеством столбцов и строк (50 столбцов, 5 мм строк)

Question

Мы создаем решение для кэширования наших пользовательских данных.В настоящее время данные хранятся в sybase и распределяются по 5-6 таблицам, но служба запросов построена на них с использованием hibernate, и мы получаем очень низкую производительность.Чтобы загрузить данные в кеш, потребуется от 10 до 15 часов.

Итак, мы решили создать денормализованную таблицу из 50–60 столбцов и 5-миллиметровых строк в другую реляционную базу данных (UDB), сначала заполнить эту таблицу, а затем заполнить кэш из новой денормализованной таблицы, используя время JDBC.построить нам кеш ниже.Это дает нам гораздо лучшую производительность, и теперь мы можем построить кеш примерно за час, но это также не соответствует нашему требованию построения кеша за 5 минут.Денормированная таблица запрашивается с использованием следующего запроса

select * from users where user id in (...)

Здесь идентификатор пользователя является первичным ключом.Мы также попытались выполнить запрос

select * from user where user_location in (...) 

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

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

Какое решение NOSQL подойдет для наших нужд.Помимо большого стола, мы будем ежедневно делать около 1 мм обновлений на столе.

Я читал о mongo db, и кажется, что он может работать, но никто не опубликовал никакого опыта с mongo db с таким количеством строк и таким количеством ежедневных обновлений.

Пожалуйста, дайте нам знать ваши мысли.

Answer 1

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

http://www.mongodb.org/display/DOCS/The+Database+and+Caching

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

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