Початок стосунків з MongoDB

Щойно я нормально так прозрів на рахунок MongoDB і того чому в мене від неї відпадали курсори, а запити були тугими. І йомайо яка це чудова база даних! Вона настільки приємніша за реляційні, наскільки мови з динамічною типізацією приємніші за мови зі статичною. 😛 І як Python – спочатку неймовірно проста, але чим довше знаймишся – тим більш глибокі можливості відкриваються.

Задача яку я розв’язував – підрахунок частоти послідовних трійок токенів в тексті, де токен – слово, пунктуація, або невидимі символи (переноси рядків, прогалики, табуляції). Вже при 20000 трійок кожен запис в базу займав 200 мілісекунд. Це від того, що перед тим як додати одиничку до кількості трійок певного виду потрібно їх в базі даних знайти. Але так як токенами може бути пунктуація, більшість трійок, це “після слова йде кома, після коми прогалик”. Зрозуміло що після кожної коми повинен йти прогалик. А після коми з прогаликом з майже однаковою ймовірністю може йти купа різних слів. Тому трійок для того аби згенерувати текст статистично схожий на текст певного корпусу – мало.

І я вирішив перейти до масиву. Тобто записи в базі даних будуть виглядати як словник з трьох слів та кількості вживань, а словник з списку трьох слів, слова яке йде за ними та їх кількості вживань. Але індекс по списку не дуже то допоміг. А все виявилось тому, що індекс по масиву дозволяє навіть перевіряти входження елемента в список. Чи входження всіх елементів списку в список. Зрозуміло що розмір індексу, зростає так немало (тому напевне на розмір ключа встановлено обмеження не більше 800 байт), та й витрати часу на запити теж. Тому краще повернутись назад до індексу по окремих скалярних полях документа. І всьо повинно бути чотко!

А про те що з того вийшло – трохи пізніше.

Література:

• http://stackoverflow.com/questions/8914635/optimizing-for-exact-array-matching-over-mongodb-collection
• http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo

Advertisements