• MySQL
• SQL

Бих искал да попитам някой как да се реши проблема с търсенето на тагове. Какъв софтуер.

Двете основни условия:
1) проблем - системата трябва бързо (

1-50 милисекунди), за да отговорят на въпроса в духа на "намери на всички документи, в които има (1-етикет или етикет-таг-30 или 100 500 или.) И (таг-етикет 50 или 1000, или.) И.". The или може да бъде до двадесет тагове, и при условия, може да бъде десет.
2) Тъй като данните могат да бъдат актуализирани често, тогава ще трябва да се постигне минимално време за актуализирането на промените.

Опитах се да направя, за да се използват видове Redis и SET BITMAP (подобно тук, "Бързо филтър каталог за онлайн магазини."). SET не е набирала (в комплекта поддържан и документи за самоличност), тъй като дори и в случай на кръстовището на две групи от 100k мисли дълго, отколкото е необходимо. BITMAP не се приближи поради изключително изтощен от документи за самоличност, в резултат на допълнително консумацията на памет на "дупки". По принцип, ако множество големи, Redis е изваждането от кутията пасва лошо.

Сега тя работи по версия на Сфинкса. ID тагове, които са написани на sql_attr_multi. Това гарантира, че определените изисквания за скорост на търсене. Изискване Тази актуализация се отнася до изграждането на основната и делта индекса. Основният индекс (на която поведение търсене) обявен за разпределено. По същество това работи добре, но понякога това е много нови промени и индекс делта започва да се забавя. За да се възстанови основния индекс отнема няколко минути (сега нещо за 3,5 м документи за самоличност в тях). Изглежда, не много, но това се планира да се увеличи броят на документи в десетки пъти. актуализиране на данни, като същевременно започва да се увеличава.

Бих искал да знам дали има някакви други решения (C? Tarantool? Elasticsearch?) И кой използват така.

sim3x. С всички боклук база обхваща нещо за 4GB. Т.е. Да, всичко в паметта идва. Но това няма значение как се чувствам, защото за текущата задача е много глупав ID представляваща неподписан 32-ия вътр. Ако ги карам в широк Redis (по схемата: The Key "tagId.ID_tega" (например "tagId.100"), определена стойност, в които документи за самоличност, свързани с този етикет, т.е., ID на документа се дублира много пъти), се оказва, нещо някъде около 2.5 GB.

Алекс гърдите.
След това е необходимо да се обърне на настройките за вашата база данни
Вижте индексите на масата, бавни заявки, като работата ви искания

Нека не до около репички мислят - има много въздушни и детайли
До цялата база данни е поставена в паметта - за оптимизиране на

sim3x. Не, не е така. По същество е OR. Освен първоначалната задача е доста по-различно. Необходимо е "да го намерите на всички документи, които имат (таг-таг 1 или 500 или маркер на Н.) И (таг-етикет 20 или 30) I.". Други опции, но да се присъединят, аз не виждам. Като цяло, в рамките на RDBMS не работи правилно.

sim3x. Това не е така, знам. За разширяване sishnoe под postgri Аз със сигурност, че, но ако чисто sishny код не може да се направи на кръстовището на N набора (представляваща INT) по-бързо от Сфинкса, димът средство по посока разширяване sishnogo под строим по-рано. Аз със сигурност се разбере, че най-вероятно няма код най-добрите и има какво да мислим за това, но аз не sishnik това по собствена воля не са готови. И тъй като проблемът не е единствена по принцип, аз някак си се надявам, че някой друг вече е създал нещо подобно под формата на завършен библиотека. Това ischyu.

Алекс гърдите. в Postgres стандартно пресичане
Sishnoe разширение е необходимо вече изчерпани, когато кеширане възможности за клиенти

Според определени параметри, избрани документи от по-малко от секунда
група на документи в рамките на две седмици (без значение колко документи) се избира по-малко от 10 секунди
максималното време за вземане на проби от всички етикети и 20 минути документи

сървър в долната - един процент до 8 ядра, 58 GB памет, с този сървър има 32 бази са широко използвани (само задвижва добро)

Научи Math част
- секциониране
- индекси
- файлови групи
- Inmemori

База 4 концерт :))))) Аз имам тази база от 700 GB и 100 GB маса по-личен начин normalnenko, много бързо избран :)

Разбира се на други платформи, също могат да се оптимизират

По дяволите!
База 4 Giga - Карл. чуете 4 Giga Карл.
(С вашия проблем само индекси бяха XS знае колко много ми тежи индекси повече от 1,5 пъти на данни)

igruschkafox за мен втори е дълго време. (И аз имам MySQL). Филтърът трябва да работят не повече от 50 милисекунди. примитивен поле маса на 2 (което Int-и) tagId, Док nakosyachit доста трудно. И има записи на само 4 М. Изглежда, че всичко е просто. И тя работи. Имам нужда в контекста на твърде бавен. Колко време имаш в базата данни отива в отговор на въпроса ", за да намерите документи за самоличност, в която има (таг 1 или таг-2 или таг-10) и (таг 100 или маркер 200 или маркер 300.) И". т.е. същество обичайно IN () и В () и В (). в същото време по такъв проба поне няколко маркери, свързани с повече от 100k документи. Нека да е до 10 маркери в ПО, както и такива условия за максимално от 10. Той също така изглежда като искане и как се извършва?

За разделяне, което знам. Тук бих искал да направя, за да PostgreSQL чрез наследяване таблици.

машина Vobnyh

Оставям като забележка за историята. В този момент в сфинкса на веригата получите най-бързо. Въпрос с индекс делта впуска само част от неговата повторно преброяване на гласовете. Сега приложението следи неговия размер и най-скоро, тъй като има повече документи 20k, стартирайте rotirovanie. Той е получил необходимата скорост за вземане на проби дори и на сложни заявки.

И не забравяйте да получите всички? Но все пак, след като потребителят не е да го прочетете. Можете да получите всеки таг отделно и след AJAX-ти и затегнете. ако е необходимо, за да сортирате на клиента.