?

Log in

No account? Create an account

Previous Entry | Next Entry

У нас имеется вот такая практическая задача по хранению как бы журналов, которую мы что-то никак не решим. Может, она давно уже решена, и мы зря мучаемся?

Имеется некоторое число агентов, числом порядка десятков. Каждый агент вступает, скажем, в разговор, и в процессе записывает некоторый журнал, текстовую информацию. Для каждой строки мы записываем время, целое число — код события и, собственно, текст, до 1000 символов (в среднем 150). За 2 минуты эксперимента агент выдает где-то таких строк 200-300. Кроме того, записывается код агента и код разговора. Информация хранится 2 месяца, затем ее можно стирать. Собственно, вот и все — один последовательный файл на всех или одна таблица в базе данных.

В части запросов к хранилищу: нам хочется получать весь журнал одного агента (один агент производит единицы или десятки разговоров, и исчезает навсегда), одного разговора или запрашивать информацию по тому самому коду события. Некоторые из кодов «более важны» (они известны заранее, и их коды отрицательные); более важные записи всегда просматриваются человеком, ежедневно, несколько раз в день. Однако, запросы по другим кодам тоже приходится делать, но реже.

Сейчас это все записывается в таблицу в БД. К сожалению, вставлять записи мы успеваем (BULK INSERT), а вот удалять уже не всегда получается, DELETE просто не успевает их удалять с нужной скоростью, и эта зараза растет. Сейчас она живет на отдельном диске в 1ТБ на машине с 2 зеонами и 32 ГБ оперативной памяти. Мы добавим SSD для tempdb, но это, пожалуй, все, что мы смогли придумать по части железа. Сервер MS SQL Server 2008 на OS Windows Server 2008 R2. Все это как бы работает, только медленно немного: запрос на один журнал агента выполняется минуту-другую, а, например, всех отрицательных («важных») кодов за сегодня — минут от 8 до 25, в зависимости от погоды в Атлантике и личного расположения сервера к запрашивающему (других факторов не пока выявлено). Файлы занимают где-то 200-300 ГБ на диске, если сложить индексы, данные и database logs вместе. И пухнет потихоньку: мы и машин с агентами добавляем, и, как я уже говорил, не за два месяца там данных, а уже за 3, и все больше делается.

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

Возможно, существуют более эффективные решения, чем СУБД, учитывая простоту хранимых данных (нет модификации, только вставка/удаление; нет реляций, одна-единственная таблица), но мы их не нашли. Не думаю, что с такой проблемой столкнулись мы одни. Если знаете, как такие вещи решают — научите витающих в облаках теоретиков, как с ними справляются, а?

Доб. Кто-нибудь имел дело с Apachе Cassandra или Hypertable? Это то, что мы ищем, или нет?

Comments

_navi_
Sep. 8th, 2010 09:32 pm (UTC)
RethinkDB сейчас пишут прозрачную замену для memcached, работающую эффективно с SSD, вроде собирались релизнуть в октябре.
fregimus
Sep. 8th, 2010 11:25 pm (UTC)
Что ж, может, и доживем!

Profile

oak
fregimus
L. Fregimus Vacerro

Latest Month

August 2018
S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 

Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow