Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Пишу с нуля поисковый движок

Добрый День !
Пишу с нуля поисковый движок на Си. На данный момент проиндексировано
0,5 ТБ ресурсов, в том числе Ваш сайт.
Поиск имеет более качественную выдачу, основанную на ассоциативных связях в тексте.

Примеры запросов

Доллар
booben.com/?q=доллар&s=dou.ua

Трактор:
booben.com/?q=трактор&s=dou.ua

Хмиль
booben.com/?q=хмиль&s=dou.ua

Также Вы можете отслеживать популярность тех или иных терминов на Вашем сайте:

booben.com/...​tat?q=джава шарп&s=dou.ua

UPD: Поиск по фразам работает

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Кто-нибудь может объяснить почему топикстартера начали обливать говном? Вроде бы не очередной v-search пришел презентовать.

А потом дядя Азиров стучит по столу и допытывается почему до сих пор не написали украинский гугл

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Немного ТТХ по этому проекту.
Общее количество ежедневно индексируемых сайтов составило 15 (+4 сайта за последний месяц)
Общее количество проиндексированых страниц за пол года 1 миллион 66 тысяч (стянуто пауками)
Общий размер индекса 690 мб (да да, я не врал когда говорил что на 3х терабайтник залезет весь индекс на два рунета при сжатии то 99%, лол :) )
Общий размер контента к нему 4,1 гб (это в зип архиве, я настроил джобы архивации страниц и реиндексирует прямо из архивов)
Помимо основных поисковых функций
общее количество кубов, картинок, видео, гифов
booben.com/...youtube jpg bgif&s=online

Последняя добавленая фича, смарт поиск гифов более 1 мб
booben.com/...f+1&s=online&a=search&p=1

Предпоследняя добавленая фича, поиск кубов на соц ресурсах (наиболее интересных)
booben.com/...b+1&s=online&a=search&p=1

Какая у твоего поисковика средняя дневная аудитория за последний месяц?

учитывать те дни когда сервер был выключен с розетки ? :)

Ну да, гдето так. От 100 до 1000 поисковых запросов в сутки.
Пока что это не готовый продукт. Хотябы потому, что поисковые базы
не обновляются с мая 2014 года.
Но есть и позитивные новости, теперь можно строить фасетные запросы, например найти страницы где больше всего матерились :)
booben.com/...ва+UAH+&s=dou.ua&a=search

Хехе, прикольно. Успехов с поисковиком!

От 100 до 1000 поисковых запросов в сутки.
Кто все эти люди?

Легко и незатейливо обошли «укр нац поисковик» Шукалку :)
О Шукалке: tsn.ua/...nalniy-gugl-shukalka.html

Пруфы по рейтингу:
www.alexa.com/siteinfo/shukalka.com.ua
www.alexa.com/siteinfo/booben.com

Возможно следующий на очереди Спутник =)

Добавил статейку в блог: Ляпы Яндекса и Гугла
blog.pikosec.com/?p=132

Господа, прикрутил поиск по фразам, подробности позже :)

booben.com/...рам аджайл&s=habrahabr.ru

booben.com/...ua&q=booben&p=0
Так на самом деле должно быть?

booben.com/...ботаны&s=dou.ua
Крутой ассоциативный ряд.

Село и рожать стоят рядом.

По многим поисковым запросам выскакивали не менее непредсказуемые ассоциативные ряды.
Начал играться и угадывать наперёд (до нажатия кнопки), что мне на этот раз система подсунет. Весело и прикольно.

Что я вам скажу...
Гигантов вряд ли можно переплюнуть. Как для интранета поисковик будет пригодный — не знаю.
Делайте упор в сторону этих рядов, можно какую-то игру придумать на базе этого.

Коментар порушує правила спільноти і видалений модераторами.

Прикрутил прикольную фичу, «Подсветить найденые результаты».
Правда не на всех форумах ровно работает, но работает =)

Вобщем, для тех , кто не в курсе, открою секрет успешности любой поисковой системы !!!
Внимание.
Значит самый важный момент, что бы при поиске фразы —
«answer to life, the universe and everything»
Поисковая система возвращала «42».

Ну что, первая ласточка с фразами. Пока с ранжированием я весь в размышлениях и экспериментах. Поэтому пока что решил реализовать поиск по точному вхождению фразы.
Это стоило мне немного субботних нервов, ведь в одной таблиц эпические 33 млн фраз ! А по моим скромным расчетам, если переиндексировать существующие ресурсы, то размер увеличится до 150 млн фраз в одной таблице на одном инстанце.
Впрочем не будем о космическом, а вполне о земном.
Пилот уже работает на двух ресурсах.
Подробнее здесь: blog.pikosec.com/?p=109

А не пробовал в индексе хранить позицию слова, тогда тебе не понадобится хранить фразы, а достаточно пересечь списки с позициями.

А представь что одно слово у тебя встречается в 5 млн доков, второе в 10 млн. И как, пересечение быстро будет работать ? У меня же поиск фразы из двух слов сводится к одному запросу по кей валью в СУБД.

Ну так пацанский поисковик все равно с такой ситуацией столкнется, если юзер будет искать не по фразе, а просто по двум словам.
Ну и тебе до 10млн доков дорасти нужно, и думаю это не проблема, как широко известно, ВымяДБ обрабатыбает милларды запросов в секунду.

Ну так пацанский поисковик все равно с такой ситуацией столкнется, если юзер будет искать не по фразе, а просто по двум словам.

По просто двум словам пользователь никогда не ищет. Зачем ему результаты где одно слово встретилось в начале документа, а второе в конце. Таких документов будет в сто раз больше чем документов где оба слова встретились в словосочетании.

Ну и тебе до 10млн доков дорасти нужно, и думаю это не проблема, как широко известно,

Они уже по сути есть, на часто используемые слова.


ВымяДБ обрабатыбает милларды запросов в секунду

В ИнМемори режиме. На харддрайве все уже не так оптимистично.
Да и я вчера смержил два индекса (три ресурса уже), итого 54 млн 20 байтных ключей в
одной таблице VymaDB о_О
Но ничего, не треснула :)

По просто двум словам пользователь никогда не ищет
Что бы указать контекст, типа java linkedlist, иначе если задашь просто linkedlist то куча другого вылезет
В ИнМемори режиме. На харддрайве все уже не так оптимистично.
Неужели ВымяДБ не торт?
Что бы указать контекст, типа java linkedlist, иначе если задашь просто linkedlist то куча другого вылезет

И что оно тебе даст. Тема, например, про С++, а java встретится в конце где-нибудь в каментах.

Неужели ВымяДБ не торт?

Не торт по сравнению с чем ?

И что оно тебе даст. Тема, например, про С++, а java встретится в конце где-нибудь в каментах.
Если релевантность нормально считается, то такая страница будет на 100500-ой странице выдачи
Не торт по сравнению с чем ?
Похоже по сравнению со всем.
Похоже по сравнению со всем.

Недавно один мужик, предложил мне пари на 1 тыс уе что мои бенчи врут.
Я немного подумал и согласился. Он отказался, но потом предложил 20 уе если я запилю кнопку Донейт.
Ты хочешь принять его ставку ? :)

У тебя есть бенчмарки по работе ВымяДБ с диском? Ну и я твои бенчмарки смогу заверефицировать когда ты выпустишь версию под линукс. У меня в хозяйстве нету виндовс машин.

В основном инмемори бенчи. С диском достаточно примитивные. Тоесть вставили XX миллионов записей, зафлашились (сериализировались) на диск.

И с какими базами ты проводил сравнения?

Пока не с какими не проводил.
С точки зрения вставки, там все тривиально. Сначала инмемори режим, потом флаш на диск страниц памяти. С поиском все сложнее, поскольку нужно прикрутить LRU механизм. Без LRU все профиты алгоритма могут быть сведены к нулю. Потому я считаю InMemory тесты наиболее «чистыми», не зависящими от алгоритмов кеширования.

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

отому я считаю InMemory тесты наиболее «чистыми», не зависящими от алгоритмов кеширования.
Но они не применимы к реальности.
С диском может много разных стратегий быть с разными результатами для разных операций, не только в LRU суть.

Да там все стратегии похоже на попытку выловить мух. При сползании с ОЗУ на механический HDD скорость падает примерно на два три порядка. А дальше пляши как хочешь.

Но они не применимы к реальности.

Почему не применимы. Наоборот, они основа. Вот например при индексировании я выставляю в конфиге макс. обьем используемой памяти, допустим 1.2 ГБ. Как только таблица разрастается до таких размеров, сразу делается флаш на диск страниц и мержинг кусков индекса, потом всё по-новой.

Да там все стратегии похоже на попытку выловить мух. При сползании с ОЗУ на механический HDD скорость падает примерно на два три порядка. А дальше пляши как хочешь.
Логично, это главный затык, и его решение наиболее интересно в разрезе реальных задач.
Почему не применимы. Наоборот, они основа. Вот например при индексировании я выставляю в конфиге макс. обьем используемой памяти, допустим 1.2 ГБ. Как только таблица разрастается до таких размеров, сразу делается флаш на диск страниц и мержинг кусков индекса, потом всё по-новой.
Т.е. без эфективбых дисковых операций никак, о чем и речь.
Логично, это главный затык, и его решение наиболее интересно в разрезе реальных задач.

Ну я тебе скажу, если алгоритм в RAM не альфасамец, то на HDD тоже чуда не произойдет. Просто HDD это такая тормознутая вещь, что любые профиты может свести к нулю. Это примерно как разрабатывать супер пупер мега алгоритм, а потом тебе говорят, что будем все хранить на ленте. И ты как не крутись, с ленты ничего не выжмешь.
У меня сейчас несколько сотен поисковых запросов в секунду по таблице которая лежит полностью на HDD, без LRU. В таблице 54 млн 20ти байтных ключей. Я даже не знаю хорошо или это плохо. Наверное плохо, нужно прикручивать что-нибудь с кешированием.

Но мердж индексов двух разных слов, как делают все другие поисковики, ты как то ниасилил.

Осилил, даже успел раза три переписать, оптимизируя раз за разом.

НУ молодец, начинаешь внимать советам старших товарищей. Того смотри скоро и стемминг нормальный прикрутишь.

Скажи хоть чем известны в информационном фоне «старшие товарищи» ? Тебе то зачем все эти кей валью цацки ? :)

я предпочитаю загадочную безвестность дешевой славе

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

так как ты ориентируешся в матчасти — врядли что-то писал лично и глубоко копал.
Я здесь подробно описывал уже что я писал. С чего конкретно ты взял что я хуже джефа дина?
Какие именно у тебя претензии к моей матчасти?

Ну прошлый раз с std::map ты херню какуюто намерял :)
Вставлял 20 млн раз ключ 0 в таблицу и в счастливом неведеньи отрапортовал что std::map работает быстрее хештаблиц.

Я тебе сразу писал, я не спец в ц++, и не знаю всех значений параметров в АПИ стл. Между тем как ты видел я вполне ненапряжно написал на джава прожку с сравнительной производительностью по отношению к твоей ВымяДБ, которую как ты утверждал оптимизировал на протяжении многих лет.

Да, помним. Токио Кабинет к джава не хошь скачать потестировать ?

И какой результат этого теста будет?

fallabs.com/...t/benchmark.pdf

Ну вот я уже протестировал.
Вставка 1 млн строк + сохранение на диск = 0.6 секунд

О, чуток подтюнил конструктор субд, уже 0.1 сек :)

Это круто или некруто, и почему только 1млн записей?

По условиям этого бенчмарка 1 млн
fallabs.com/...t/benchmark.pdf

Но он вообще какойто странноватый бенч.
А самому качать ТокиоКабинет, я под виндовз сижу. Тут не так просто эти гиковские поделки тестить.

Ну ты сам себе буратино что на виндовз сидишь.

под линукс средства отладки более убогие.

Я опять же не сильно шпрехаю в этом деле, но всегда думал что GDB умеет все что нужно.

кстате нашел бенч с диском
fallabs.com/...t/benchmark.pdf

Может даже чтото потестирую

Я так понял старый индекс у тебя был по 1 слову, а новый , по паре слов (вот его то ты для фраз и используешь).

«В новом индексе ключи будут:
Ехали медведи
Медведи на
На велосипеде»

Первое , что хотелось бы заметить, что если кто то будет искать похожую фразу с поменяными словами в паре слов (например «медведи ехали на велосипеде») то ничего не найдется, ведь в индексе будет —
«Ехали медведи», а не «медведи ехали» ...

Думал и даже делал. Потом подумал что задача достаточно простая и нужно идти дальше.
И как правильно заметили, с

OCR
неохота возится.

БОМБА, проиндексировал весь севастопольский форум крымнашевцев. Неделю блин тянул. Теперь они под колпаком ассоциативных сетей. И сразу скандальное разоблачение путина ))

booben.com/...sevastopol.info

Якщо закешував, то дай можливість дивитись на кеш, а не на форум. Якщо твоя ласка

Зроби словник безпечних спец-символів, бо в тебе вони перетворються наприклад на

quot;

Так вроде на кеш смотрит. Какой запрос ?

Запит — той що ти привів вище
Мова про повний кеш сторінки

Кеш есть, читается с дисков. Иногда бывает диски отключены, тогда тянет аджаксом оригинальные страницы с инета.

Блин, у меня почему то твой поисковик, держащий миллиарды запросов — прилег, какие то прогрессбары показывает. Наверное я был миллиард первым посетителем.
Пойду поищу про путин и евреев на v-search.org.

Мож и держит миллиард, ток у меня домашний тырнет с тарифом 5$/мес. Позвоню им обматерю почему мне миллиардного пользователя забанели

Еще и фильтр гады специальный поставили, прогрессбары пропускают, а результаты запроса неа.

Кстате а как ты про евреев узнал если тебя забанили ?

Ну первую страницу результатов оно показало, я потом хотел дальше покликать, ан нет, наверное кто-то понял что я начал что то подозревать.

Так это норм. Вторую страницу он аджаксом тянет оригинальные страницы.

А, так це ви мабуть поклали їхній сервак :) Вони три дні в офлайні були, тільки оговталися, кажуть госдеп їх ддосив.

Да, он чето лег. Ну ничего, у меня теперь есть полный бекап этого форума :)

Ну и потом, ребята как вы ассоциации подбираете ?
------------------------------------------------------------------------
> телега

Наши ассоциации:

телега наиграли скрипуча телеге малейшие ухом казла скрипела pocemu soccer пожимает сержант паджеры попечите тепеть ссо помешате телеграм доделку жиге победимы r19 раздевае 16кг веха
------------------------------------------------------------------------
// Это для skoda-cloub

Вот хоть убей но я не могу придумать никакой явной связи между словами телега и наиграли (ну там еще пол списка), может я что то пропустил...

Базу покрупнее можно взять:
booben.com/...телега&s=sql.ru

телега телегу телеги телеге лошади телегах телег арба акпп повозки повозка мобила подзабил телегой лошадью лошадь ...

Вот хоть убей но я не могу придумать никакой явной связи между словами телега и наиграли (ну там еще пол списка), может я что то пропустил...

Там если Вы почитаете ссылки, то есть пользователь по имени Телега, который играет в футбол. В терминах этого форума — результат корректный. На другом форуме будет другая терминология :)

Давайте соствим цепочку логических ассоциаций.
(Телега) -> пользователь -> играет в футболл -> его (наигрывают)
Что то мне кажется, что с таким уровнем ассоциаций можно подобрать половину слов русского словаря.

Здесь все зависит от базы и ее размеров.
На маленьких базах невозможно получить качественные ассоциации.
Возможно для поиска по маленьким форумам прийдется подключать большие «эталонные» базы, но тогда маленькие форумы, которые переопределяют значения терминов, потеряют свою индивидуальность. Например на форуме правоохранителей телега будет иметь значение телеги с лошадью. Хотя в их жаргоне, телега = донос. Фишка поиска в том что алгоритм обучается как раз на той базе по которой ищет, а не мешает все в одну кучу.

Я вижу даже наш Черкасский форум в списке есть, чем он удостоился такой чести? :)

Он достаточно крупный и популярный.
Мне советуют ресурсы — я индексирую. :)

Ну вот какого то Киевского портала нету, ну и чего то подобного webmasters.ru тоже нету. Не, ну я ж не могу быть против того, что вы форум моего средней крупности города ставите в ряд с searchengines и Хабром, как тут поспоришь? :)

Ребята , вы не обижайтесь но это фигня, по крайне мере на данном этапе.
Что бы не быть голослоным привожу пример —
поиск по слову «fake» :

1)
login_exisinguser_hashreturned() { // arrange orderprocessor = mock of<iorderprocessor>(); orderdata = mock of<iorderdata>(); layoutmanager = mock of<ilayoutmanager>(); newsprovider = mock of<inewsprovider>(); service = new iosservi
---------
2)
у себя в памяти и заполянем своим же кодом, то эта зависимость становится внутреней. по классификации фаулера — это fake object. 0 dborovikov, 30 сентября 2011 в 12:23 # ↵ ↑ и тестирование на fake базе — это юнит-тестирование. 0 idsa, 30 сентябр

// Может и не плохо, что ваш «умный» движок решил, что интересуещее меня слово — fake это то тоже самое , что и слово mock. Но !!!
в результаты ранжирования должны отображать приоритетность искомого слова в изначальной форме (fake) над его «синонимами» (mock).

P.S Кстати , когда мы писали наш (associative search engine) то в базе синономов некоторое время было так, что все слова с морской тематикой подменялись на слово «авиаматка».

Ребята , вы не обижайтесь но это фигня, по крайне мере на данном этапе.
Что бы не быть голослоным привожу пример —
поиск по слову «fake» :

Кстате а вы в гугол забивали ваш запрос ?
www.google.com.ua/...brahabr.ru fake

В частности в топе «На приёме у врача: играем в Ingress без GPS»
Это хотели увидеть по запросу fake ?

Если меня спросят что такое fake в айти, то первое что прийдет в голову это моки и фейковые обьекты. И весь топ моим движком честно отдан этой тематике:

booben.com/?q=fake

В остальном, критика привествуется, это прототип с который еще предстоит допиливать.

В частности в топе «На приёме у врача: играем в Ingress без GPS»
Ну если открыть статью то там слово fake играет намного большее змачение чем у тебя в первой строчке выдачи

Я бы сказал что гугол попался на удочку и сделал релевантной статью, которая слово fake употребляет в достаточно случайном редкоупотребляемом смысле. А у меня движок построен на принципах демократии. Если айтишный мейнстрим задал что фейк это фейковый обьект, значит так тому и быть. И всякие fake GPSы будут в меньшинстве без права на топ.

ну или твой движек кривой:
site:habrahabr.ru fake mock — 47 results
site:habrahabr.ru fake gps — 136 results

Когда прийдешь на собеседование и тебя спросят что такое fake, будешь рассказывать про GPS. Яж не против :)

Очевидно от конторы зависит. Слово фейк без контекста вообще может что угодно означать eсли ты не в курсе.

habrahabr.ru fake mock — 47 results

Добавь сюда все что там есть в ассоциациях.
fake mock, fake object, fake factory, fake repository, fake container, фейковая фабрика и тд ...
и посчитай голоса :)

А как именно ты предлагаешь считать?

Предлагаю удалить Гугол из закладок и пользоваться Бубном.
Он уже все за тебя посчитал и покажет как надо :)

Я гуглом и не пользуюсь, только v-search.org

Взерч мошная штука, спору нет.
Но зацени еще один эпик феил гугла:

www.google.com.ua/...ahabr.ru ельцин

Ватефак, что за выдача в стиле алтависты 96го года ?
Другое дело вот:

booben.com/...&s=habrahabr.ru

Такшта распродавай акции гугла !
Нормальные посаны уже все распродали и ждут чтоб вложится в незалежный хохлопоиск.

Ну ты то страницы которые выдал гугл в топе вообще не проиндексировал, непонятно какой ранк бы им твой движек поставил бы

коменты у меня все проиндексированы вместе с статьями на хабре

Ну там гугл показывает профайлы юзеров с лентой коментов

результаты ранжирования должны отображать приоритетность искомого слова в изначальной форме (fake) над его «синонимами» (mock).

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

Наскольк я понял, за несколько лет разработки поисковика, оптимально подобранный алгоритм ранжирования (как модно говорить — интеллектуальный) это 50 % успеха системы.

Потом тут приводят пример не совсем правильного поиска (выдачи результатов на гугл). Я хотел бы посмотретьна заказчика, который говорит — вот тут система работает не правильно, а разработчик в ответ — да , система работает не совсем правильно, но гугл, в этом случае работает еще хуже.

Вообщем я думаю вам ребята нужно усовершенствовать алгоритмы ранжирования, и все будет гут.

Я хотел бы посмотретьна заказчика, который говорит — вот тут система работает не правильно, а разработчик в ответ — да , система работает не совсем правильно, но гугл, в этом случае работает еще хуже.

Это не совсем так, если говорить о алгоритмах нечеткой логики. При алгоритмах нечеткой логики нет 100% результата, просто по определенным критериям система дает свою оценку и не гарантирует что результат будет правильный. Врядли если разработчики в гугле увидят мой пример с хабра, замешкаются и сядут переписывать гугол, просто отметят что есть вот такой случай.

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

Мне нравится, немного долго, конечно, выполняется поиск, но, думаю, вы работает над оптимизацией. В общем, даже ничего так

Неплохо. Думаю проект вполне себе имеет право на жизнь. Есть несколько вопросов:
— Есть ли конкуренты? (в данном контексте — поисковые движки написанные на Си, быстрым гуглингом не нашел);
— Под «ассоциативными связями» я так понял имеется в виду контекстно-частотный анализ (вес слова фактически == частоте встречаемости) или используется другой подход?
— Судя по всему постоянного кравлинга нету. При добавлении новых доков надо перестраивать индекс? При перестройке нужно ли еще раз обрабатывать все данные заново?
— Быстрота, как я понял, за счет того, что весь индекс помещается в RAM, что планируете в случае если индекс больше доступного RAM?
— Бенчмарки с другими решениями на одинаковом инпуте? (Сфинкс, люцен)

Есть ли конкуренты? (в данном контексте — поисковые движки написанные на Си, быстрым гуглингом не нашел);
Есть. Вроде VisualWorld.ru — но качество там вообще никакое.
Под «ассоциативными связями» я так понял имеется в виду контекстно-частотный анализ (вес слова фактически == частоте встречаемости) или используется другой подход?
Там целый алгоритм с нескольких этапов. Долго писать.
Судя по всему постоянного кравлинга нету. При добавлении новых доков надо перестраивать индекс? При перестройке нужно ли еще раз обрабатывать все данные заново?
Пока нету, в ручном режиме. Но впринципе не сильно напрягает, поскольку в среднем сайт качается около недели. Поставил и ждешь.
Быстрота, как я понял, за счет того, что весь индекс помещается в RAM, что планируете в случае если индекс больше доступного RAM?

Там часть индекса лежит в РАМ (индексы на 9 форумов), та что Либрусек лежит на диске.

Бенчмарки с другими решениями на одинаковом инпуте? (Сфинкс, люцен)

Не сравнивал, поскольку задачи немного разошлись с этими системами. Там обычный поиск с сортировкой по аттрибутам локальных хранилищ.

Форум форекс клуба покорился и лёг в поисковик.
Теперь разные термины связаные с трейдингом, валютами да и политика доступны в разборе обученых ассоциативных сетей:
booben.com/...кс&s=fxclub.org

Также добавил пару статей в блог по сжатию данных:
blog.pikosec.com

А почему это должно быть интересно юзерам, что слова " евре" и " продават" как то связаны?

Какой запрос ? Может там евреи имелись ввиду :)

Ну я по твоей ссылке прошел.

это ты взял хвост списка, там в самом начале наиболее близкие по ассоциациям слова. В конце уже такой себе или муссор или чтото близкое к нему.

Та без разницы, какую пользу я получу если увижу «бакс евра вниз вверх» в твоем списке?

Также добавил пару статей в блог по сжатию данных:
blog.pikosec.com

Итак, чтобы построить RDBMS хранилище инвертированого индекса, нам понадобится три таблицы и стандартная модель связи многие-к-многим:

Двойка, все развитые РДБМС поддерживают типы данных вроде массивов, в которые ты можешь засовывать свой инвертированный индекс.

Какие тогда будут таблицы в БД ?

Таблица документ, с ключем АйДи документа, и полями вроде его УРЛ.
И таблица индекс: ключ — слово для поиска, поле массив с айдишниками документов.

Понятно. В раз 100 такая структура будет медленее работать, потому что будет требовать минимум два seek на разных таблицах. Ну и сжатие это не совсем то сжатие о котором речь в статье. В моем индексе в одном байте может упаковываться до 64 слов. Если ты будешь просто массив айдишников документов в массиве хранить то тебе это практически ничего не даст, кроме ограничений на запросы.

Ну ты не потрудился описать какую волшебную схему ты придумал для НоСкл, которая «в одном байте может упаковываться до 64 слов».

В раз 100 такая структура будет медленее работать
По сравнению с чем? Если по сравнению с твоей рукожопной схемой в рдбмс, то моя в 100 раз быстрее будет работать, так как у тебя то айдишники хранятся в разных строках таблицы, и на каждый может потребоваться отдельный сик.
Если по сравнению с твоей рукожопной схемой в рдбмс

Ну так есть мнение что любая схема в РДБМС будет рукожопной по сравнению с NoSQL :)
Мне не дает покоя мысль, а что если взять и стандартный тест TCP-H натянуть на NoSQL. Ну там замоделировать сеть складов и отгрузку товаров заказчика. Что если там тоже данные будут хранится компактней в пару десятков раз и запросы будут летать. Вотето будет челендж :)

Ну так есть мнение что любая схема в РДБМС будет рукожопной по сравнению с NoSQL :)
Но ты умудрился придумать в 100 раз рукожопнее
не не дает покоя мысль, а что если взять и стандартный тест TCP-H натянуть на NoSQL. Ну там замоделировать сеть складов и отгрузку товаров заказчика. Что если там тоже данные будут хранится компактней в пару десятков раз и запросы будут летать. Вотето будет челендж :)
Пока есть трудности с ACID у носкл, которые необходимы для этого теста
Пока есть трудности с ACID у носкл, которые необходимы для этого теста
Есть мнение что роль ACID для энтерпрайза сильно преувеличена. Например есть неплохие решения где просто два InMemory сервера зеркалируют друг друга и сидят на разных источниках питания.

АСИД очевидно решает проблемы изоляции и целостности транзакций, грубо говоря что бы один билет не продали двум васям.

Решается обычной блокировкой. Не проблема для NoSQL.

Давай конкретно, возьми свою любимую носкл, и расскажи как ты смоделируешь данные, и что ты там блокировать будешь?

«Обычная блокировка» это до какого уровня? А если участвует несколько отдельных записей на транзакцию в огромной таблице, в которую желательно пустить и остальных?

Вариант блокировки по таблицам целиком проходили (например, mysql на myisam или до сих пор так делает, или делал совсем недавно), и этот вариант, конечно, работает — в плане обеспечения надёжности фиксации изменений, при отсутствии проблем в остальной поддержке — но скорость, которую он даёт в таких условиях, в разы меньше той, что можно обеспечить чуть более гибким подходом.

Поэтому и изобретают все эти изоляции транзакций, выбор пессимистичного (с явными блокировками) или оптимистичного (с развешиванием «контролек» на чужие изменения), регулировкой блокировок по таблице, странице, отдельной записи, разные виды журналирования и т.п. — чтобы дать оптимизировать работу под конкретный случай (и как минимум не сильно хуже, чем у конкурентов).

NoRel движки (этот термин лучше, чем NoSQL — SQL сейчас даже к Berkeley DB привернули) — оптимизируют каждый свой частный узкий случай, причём, к сожалению, очень часто делают это криво, из-за недостатка сил или чрезмерной оптимизации под одну специфическую задачу. Для общего же случая, когда ещё неизвестна специфика, лучше таки начинать с чего-то традиционно реляционного, даже если как key-value с отдельными индексами.

К Вашей теме поисковика это вряд ли относится (очень специальные задачи и структуры данных под них, нет необходимости в ACID, живость базы даже на 90% обеспечивает хороший поиск при отсутствии проблем учёта) — но для 99% остальных реляционка это база и необходимость.

Важнось блокировок обратно пропорциональна скорости работы СУБД. Представьте что у вас СУБД выполняет, скажем, 100 тыс запросов в секунду. Тогда все эти 100 тыс пользователей можно просто ставить в очередь и при этом они друг другу не будут мешать и отклик будет менее секунды.
В реляционных СУБД действительно не все так радужно. Там есть блокировочники и версионники и выдуманы куча уровней изоляции, блокировки иногда спускаются на уровень записей. Связано это в основном с тем, что там гоняют тяжелую аналитику, а не короткие ОЛТП запросы.

Представьте что у вас СУБД выполняет, скажем, 100 тыс запросов в секунду. Тогда все эти 100 тыс пользователей можно просто ставить в очередь и при этом они друг другу не будут мешать и отклик будет менее секунды.

Это Вы почему-то автоматически предположили действие (я пока не говорю «транзакция») в один запрос. Реальные бизнес-задачи типа «зачислить денег на счёт» могут выполняться в десяток запросов, между которыми клиент анализирует ответы и выбирает дальнейшие действия (например, на счёт какого менеджера зачислить проценты и по какому курсу?) Для ускорения это может попасть в хранимую процедуру, но всё равно в один выстрел не уложится. Вот тут и начинают работать все возможности по устранению конфликтов, потому что впараллель будет десяток или даже тысяча транзакций...

В реляционных СУБД действительно не все так радужно. Там есть блокировочники и версионники и выдуманы куча уровней изоляции, блокировки иногда спускаются на уровень записей.

Да, сложности есть. Но это отражение реальной сложности и важности задачи, а не «не всё так радужно». Если бы была только одна принципиальная реализация, это бы значило, что мы чего-то не понимаем или не использовали ещё на полную идейную возможность.

Связано это в основном с тем, что там гоняют тяжелую аналитику, а не короткие ОЛТП запросы.

Повторюсь — OLTP запросы ой не обязательно короткие. Простейшая задача типа перевода средств между счетами двух мобилок, например, выливается в десяток изменений в разных таблицах типа «суммарные переводы за текущие сутки по абонентам категории R14».

Повторюсь — OLTP запросы ой не обязательно короткие. Простейшая задача типа перевода средств между счетами двух мобилок, например, выливается в десяток изменений в разных таблицах типа «суммарные переводы за текущие сутки по абонентам категории R14».

Я бы интеграционных монстров не приводил в пример. Там 99% времени уходит на оверхед и только 1% какаято полезная работа. Здесь я немного описываю эту проблему
blog.pikosec.com/?p=69

Я бы интеграционных монстров не приводил в пример. Там 99% времени уходит на оверхед и только 1% какаято полезная работа.

Согласен разве что в варианте, что SQL как язык — заметный оверхед. В остальном — оверхед от отдельного ведения базы от движка логики не существенен, а польза — огромная.

Реальные бизнес-задачи типа «зачислить денег на счёт» могут выполняться в десяток запросов, между которыми клиент анализирует ответы и выбирает дальнейшие действия (например, на счёт какого менеджера зачислить проценты и по какому курсу?)

Все зависит от того, как написана система. У одних нужно час просидеть в отделении маленького банка пока «компьютер посчитает». У других (процессинг Виза например) 2 млрд выпущеных карт, сотни миллионов транзакций в сутки и все летает.

У меня кстате когда контент индексируется, нагрузка на внутреннюю базу NoSQL несколько сотен миллионов запросов в час. Все построено на очереди, все летает. Узкое место — HDD.

Все зависит от того, как написана система. У одних нужно час просидеть в отделении маленького банка пока «компьютер посчитает». У других (процессинг Виза например) 2 млрд выпущеных карт, сотни миллионов транзакций в сутки и все летает.

Мнэээ... ну Вы не сравнивайте яблоки с паровозами. Процессинг Визы, например, это никак не единая система, это практически раутер, который переводит к процессинговым центрам банков. Уровень сотни миллионов, скажем, SSL-соединений за сутки на системе мирового масштаба это не уровень:) А вот конкретный процессинг уже имеет массу своей специфики, включая минутные задержки и периодические «попробуйте ещё раз».

Но то, что я тут хотел сказать, что практически все эти системы имеют на транзакцию добавление нескольких записей в лог и апдейт нескольких акаунтов или счётчиков. И всё это безобразие должно пройти атомарно (а в случае отказа по основному телу ещё и проапдейтить счётчики отказов). Поэтому все эти утяжелённые, на первый взгляд, подходы RDBMS имеют свою колоссальную причину... (что не говорит, что их надо применять везде)

У одних нужно час просидеть в отделении маленького банка пока «компьютер посчитает».

Вот такого, кстати, не видел — где это?

У меня кстате когда контент индексируется, нагрузка на внутреннюю базу NoSQL несколько сотен миллионов запросов в час. Все построено на очереди, все летает. Узкое место — HDD.

Ну дык я и говорю — процессинг банка и поисковый движок интернета это понятия, у которых общее только то, что они на компьютерах и по IP... всё остальное принципиально различно, даже если есть слово «база».

У нас тут в разных проектах были mnesia, Riak, BDB и ещё несколько мимолётных применений других движков... у каждого настолько свои тараканы, что диву даёшься.

Более того — они практически всегда в реальной жизни НЕ короткие и транзакция далеко не обозначает бинарную операцию.
Если ТС подмешает к своим 100500 селектов столько же инсертов и апдейтов на те же таблицы — без блокировок быстро наступят вахмурки.

Но ты умудрился придумать в 100 раз рукожопнее

Ну так лучше не придумаешь. Обычная база данных с связью многие ко многими на три таблички. Нормализована по учебникам, все как полагается.
Согласен, не совсем удобный случай для РДБМС

У тебя схема неудачная, не отвечает даже первым нормальным формам — атомарности данных.

Зато работает быстрее чем твоя в сотни раз, и места намного меньше будет занимать.

Быстрее чем что ?
Вот тебе аналог запроса
select sum(...) from ... group by ...
на базе в несколько десятков гигабайт
booben.com/...=nosql&s=sql.ru
Как ты видишь, отрабатывает моментально, потому что держит сотни тысяч запросов в секунду ( ядро ).

Забавно, а груп бай там зачем? И как ты проверил что твоя схема держит сотни тысяч таких запросов?

Провел бенчмарки. Груп бай потому что нужна апроксимация графика. Вот и групится несколько точек в одну.

НУ я твоих бенчмарков то не видел.

Здесь можешь глянуть. Там внутри стоит обычный key\value storage.
wiki.pikosec.com/...maDB:Benchmarks

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

Вот для этого и нужно сжатие :) Не потому что места на диске жалко, а потому что есть возможность всю базу затянуть в ОЗУ. Вот сейчас у меня индекс на все 10 форумов сидит в ОЗУ и отьедает гдето 4 ГБ. Вестимо если бы данные не удалось пожать, то индекс был бы гиг 200 и ниокаком инмемори речь бы не ишла :)

Дык а у РДБМС сжатия думаешь не бывает?

Бывает, но не такое драконовское

Ну я писал в своем блоге, там только 30-50% будут занимать айдишники, которые noSQL может не хранить. Просто будет хранить данные «рядом». Если ты увлечешся и начнешь денормализовать базу до noSQL, то прийдешь в конечном итоге к томуже noSQL.

Я не понял слога мысли. Там, это где? В твоей рукожопной рдбмс схеме? А в моей? А что хранить вместо айдишников?

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

Я же уже тебе вроде как давно предложил свою схему?

Она не отвечает первой нормальной форме — раз.
Два — я даю тебе расчет на твою схему.
Таблица Словарь занимает = 9.7 мб.
Таблица документ занимает 140 тысяч доков * (64 байта url + 750 айдишников слов * 4 байта ) = 429 мегабайт

Итого у тебя выиграш за счет денормализации получился в два раза всеголишь. А не в 17ть раз :)

У тебя на каждую пару (документ, слово) будет сохранятся пара (document_id, term_id) + оверхед на дополнительную строку в таблице включая раздувшийся размер индекса. А у меня только document_id в массиве, разница может быть очень большая в зависимости от того сколько в тексте в среднем слово встречается в разных документах.

У меня не пары хранятся. Но не совсем понял твою структуру БД. Опиши таблицы и их колонки.

Как это не пары:

аблица связи многие ко многим между Документами и Словарем (Document_Dictionary)

Содержит колонки

DocumentID (4 байта)
DictionaryID (4 байта)

Каждая строка в таблице именно и содержит пару.

Опиши таблицы и их колонки.
Я уже детально описал, поднапрягись, прочитай еще раз.

Так я же тебе уже ответил. В нормализованом виде ( в блоге ) база будет занимать гдето 850 мегабайт. В твоем предложеном денормализованом ( там я выше привел свои выкладки ) гдето 450 мегабайт. А у меня по факту эта база весит 55 мегабайт. Ты получил выиграш за счет денормализации в два раза, но этого мало.

У тебя в твоих расчетах вообще математика из паралельной реальности, ты почему то решил что абсолютно все слова будут встречатся абсолютно во всех документах, и зачем то посчитал их декартово произведение, что однозначная муть.

Не так. Всего слов 809242. Через размер документа и среднюю длину слова я высчитал что в среднем документе встречается 1500 слов, из которых 750 уникальных. Вот на это число и умножал.

Короче ладно, если будут вопросы то уже завтра.

Ну умножал ты почему то на 1500 а не 750. Теперь в твоей кривожопной рдбмс схеме ты хранишь все пары документ-слово, что дает 750 айдишников слов * 4 байта * 140 тысяч доков * 4 байта, в мoей схеме я храною 140к * 750 * 4 байта (айдишник документа), выигрышь в 4 раза а не в «ыиграш за счет денормализации получился в несколько процентов » как ты изначально написал. Теперь если включить компрессию на таблице она вполне возможно дожмется до твоего носкл решения, но при этом будет работать и на данных не помещающихся в память, иметь кучу отточенной годами кеширующей логики, хранящей в памяти только часто используемые данные, иметь богатый язык запросов и всякую инфраструктуру.

в мoей схеме я храною 140к * 750 * 4 байта (айдишник документа)

А 64 байта куда потерял ? Где Урл документа хранить ?

И подсчет правильный такой, как я привел выше

Таблица Словарь занимает = 9.7 мб.
Таблица документ занимает 140 тысяч доков * (64 байта url + 750 айдишников слов * 4 байта ) = 429 мегабайт
Итого у тебя выиграш за счет денормализации получился в два раза всеголишь.

Тоесть выиграш не в 4 раза, а только в 2. За счет денормализации.

А 64 байта куда потерял ? Где Урл документа хранить ?
И подсчет правильный такой, как я привел выше
А ты УРЛ у себя не хранишь?
Тоесть выиграш не в 4 раза, а только в 2. За счет денормализации.
Да, здесь я ошибся, в два раза в размере, и в сотни раз в производительности если данные не помещаются в памяти.
А ты УРЛ у себя не хранишь?

Ну типо да. Урл есть в условиях задачи и он хранится. Размер фиксированый — 64 байта.

Ну так и у тебя будут такие же расходы, я сравнивал только части которые отличаются

Кстати прикольное имя для базы — ВымяДб

К слову, на этой неделе я закончил качать форум ФорексКлуб.
Общее количесто выкаченых файлов html превысило 20 ГБ.
А после индексирования из этих 20 ГБ осталось гдето 70 МБ :)
Во сколько раз сжат контент в индексе ты можешь посчитать.
Конечно немалая заслуга в этом криворуких верстальщиков, у которых одна страница занимает чуть ли не мегабайт хтмла, а полезного текста там на двадцаток килобайт в лучшем случае, но тем не менее.

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

SQL Server кстати не поддерживает вообще никак. В оракле массив можно создать в виде переменной на PL\SQL, создать колонку в таблице типа массив по моему тоже нельзя.

НУ я говорил про развитые базы, постгрес например.

то-то я смотрю оракл с MSSQL-ом недоразвитые, а 70 с хренью процентов рынка держат чисто по глупости юзверей. А постгес эффективно будет работать, если в поле типа массив запихнуть массив на 100500 элементов? Или он под каптом ту же связанную табличку построит?

о-то я смотрю оракл с MSSQL-ом недоразвитые, а 70 с хренью процентов рынка держат чисто по глупости юзверей.
это 70 процентов рынка выраженного в деньгах наверное, постгрес то бесплатный поэтому эта мерялка глупа в данном случае
А постгес эффективно будет работать, если в поле типа массив запихнуть массив на 100500 элементов? Или он под каптом ту же связанную табличку построит?
Эфективно — это понятие относительное, меня устраивает, таблив он наверное не создает.

Да это наверное в деньгах, но по популярности посгрес тоже рядом не стоял
db-engines.com/en/ranking
Ну, если там будет 100500 слов и к каждому будет по 100500 айдишник документов в котором они встречаются, то если постгрес будет просматривать каждый айдишник по очереди, то боюсь он загрустит.

Да это наверное в деньгах, но по популярности посгрес тоже рядом не стоял
db-engines.com/en/ranking
Тем не менее на примере поддержки массивов мы видим что популярность и развитость это слегка разные вещи
Ну, если там будет 100500 слов и к каждому будет по 100500 айдишник документов в котором они встречаются, то если постгрес будет просматривать каждый айдишник по очереди, то боюсь он загрустит.
Или не загрустит
Да это наверное в деньгах, но по популярности посгрес тоже рядом не стоял
db-engines.com/en/ranking
Кстати для меня самая надежная метрика популярности: это количество вопросов на stackoverflow, и вот оказалось что у оракла и постгре они более менее одинаковы

Ну, это если под популярностью понимать наличие миллионов счастливых обладателей базы на 2 таблички, судорожно вопрошающих на stackoverflow, как сделать select * from. MySQL по этому параметру раз в 5 популярнее.
А у ораклоидов для вопросов есть Аск Том, не говоря уже о службе поддержки.

Ну, это если под популярностью понимать наличие миллионов счастливых обладателей базы на 2 таблички, судорожно вопрошающих на stackoverflow, как сделать select * from. MySQL по этому параметру раз в 5 популярнее.
НУ твой рейтинг приблизительно это и делает, только еще менее таргетировано
А у ораклоидов для вопросов есть Аск Том
In the last 4 weeks, I’ve taken 0 new questions
Спасибо, поржал
НУ твой рейтинг приблизительно это и делает, только еще менее таргетировано
 Ну, во-первых он не мой, я его сам только что нагуглил, а во-вторых он все таки более коррелирует с окружающей действительностью.
Ну, во-первых он не мой, я его сам только что нагуглил
Ух ты, а я и не в курсе, потрясающее откровение

а во-вторых он все таки более коррелирует с окружающей действительностью.
А почему на стековерфлоу действительность другая?
А почему на стековерфлоу действительность другая?
Может потому, что показывает не столько популярность технологии, сколько доступность ее среднестатистическому нубу?
Как пример, попробуй с помощью стековерфлоу оценить популярность SAP.
Может потому, что показывает не столько популярность технологии, сколько доступность ее среднестатистическому нубу?
А может и не потому, ну и частеньки доступность среднестатистическому нубу коррелирует с популярностью
Как пример, попробуй с помощью стековерфлоу оценить популярность SAP.
та лехко: stackoverflow.com/...ions/tagged/sap вс stackoverflow.com/...rosoft-dynamics

1500 вопросов про САП с 26 млн на стековерфлоу.
САП загибается ?

интересно послушать твою версию

Думаю что RDBMS, будь то Оракл или Постгрес, вполне может загнуться в среднесрочной перспективе. Когда нужна постреляционность (для бизнесса сейчас это все более актуально) в этих базах начинается тихий ужас.

Какой бешенный галоп по темам, а еще недавно САП обсуждали.
Ты пока еще не привел свой подход как ты элементарную задачу продажи билетов на носкл организуешь, а рассуждаешь тут о смерти РДБМС уже.

По САП тебе bayda уже ответил. У них есть отдельный форум для поддержки и вопросов, который в раз 50 больше чем Доу.
Если нужно, могу поискать и привести ссылку.

По САП тебе bayda уже ответил.
Ну а я ответил ему.
У них есть отдельный форум для поддержки и вопросов, который в раз 50 больше чем Доу.
Если нужно, могу поискать и привести ссылку.
приведи

А откуда тогда там вопросы по сапу и абапу?

Ну тебе же написали. На стековерфлоу 1500 вопросов по САП.
А на scn.sap.com/activity — 3,6 млн вопросов.

Ты бы еще задал вопрос почему по САП на Доу так мало вопросов :)

Ну тебе же написали. На стековерфлоу 1500 вопросов по САП.
А на scn.sap.com/activity — 3,6 млн вопросов.
А как ты определил что там 3 млн вопросов?
Ты бы еще задал вопрос почему по САП на Доу так мало вопросов :)
У постгре тоже есть тематические форумы и юзерлисты, но стековерфлоу это выборка, как экзитпол.
А как ты определил что там 3 млн вопросов?
На айдишник смотри: scn.sap.com/thread/3632437

А с чего ты взял что этот айдишник инкрементируется только для вопросов?

Ты точно «хакер» ?
Не можешь определить сколько примерно тем на форуме ?

Наверное могу, и доску к потолку наверное смогу прибить, только зачем?

Если можешь так определи и не задавай совсем глупых вопросов.

Если можешь так определи
думаю абайдешься
не задавай совсем глупых вопросов.
ты просто до них еще недорос

Там же можно зайти в профиль вопрошающих и увидеть их интересы. Мало у кого там чистый сап и абап или сап в лидерах по тегам. Как правило, это какое-то параллельное направление в их карьере.

НУ tак сейчас и не так уж и много чистых абап программистов в пронципе, они сильно джаваизировались, что не означает что они не работают на сап платформе.

Подозреваю, что там скорее встретишь абапизировавшегося джависта, чем джаваизировавшего абапера. :)

Есть некоторый процент людей, который адресует свои вопросы в самые неожиданные места, например в спортлото.

Это неконструктивный аргумент, им можно с таким же успехом обьяснить твое пребывание на этом сайте.

Это я к тому, что саперы тусят на своих сайтах, а на стековерфлоу заходят изредка случайно. Если не веришь, можешь поспрашивать у знакомых саперов.

НУ так и у постгрескл есть свои сайты форумы

ну так я об этом и говорю — сравнивать популярности чего либо на стековерфлоу можно только с очень большой натяжкой

Это наиболее таргетированный ресурс, и наиболее точная метрика.

По моему метрика с того сайта куда более точная
db-engines.com/...king_definition
Стековерфлоу она в себя кстати тоже включает

А помоему нет, они там всякий мусор из интернетов учитыввают

Инет, это да, но количество профилей в проф сетях и количество вакансий показывает, как раз использование в профессиональной среде, а не в студенческих курсачах.

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

Мне кажется ты недооцениваешь Оракл и MS SQL. Это уже давно не СУБД в классическом понимании. Это уже целые фреймворки для интеграции, хранения, асинхронной обработки и еще тысячи вещей. Они разве что на дудочке играть не умеют. Многие системы просо физически невозможно перевести на постгресс. Нет джобов, очередей, репликаций, авто отправки имейло и еще десятки разной фигни которой сделало из классических субд корпоративных монстров.

Мне кажется ты недооцениваешь Оракл и MS SQL. Это уже давно не СУБД в классическом понимании. Это уже целые фреймворки для интеграции, хранения, асинхронной обработки и еще тысячи вещей. Они разве что на дудочке играть не умеют.
Все что ты написал в постгрес либо есть либо решается подручными средствами и в базе не нужно (вроде отправки имейлов, втф?)
Многие системы просо физически невозможно перевести на постгресс.
Это не из-за недостатка функциональности, а из-за использования нестандартных фич, типа синтаксических извратов в языке запросов.
Все что ты написал в постгрес либо есть либо решается подручными средствами и в базе не нужно (вроде отправки имейлов, втф?)

Видимо ты не вкусил всех прелестей ентерпрайза. И большинство вещей конечно тебе сложно понять. Помойму тут кто-то писал, какойто джавист, устроился на работу, а там база на 1600 табличек .... докрути сюда еще штук двесте разных интеграций, разных систем оповещений, имейлов, джобов, витрин, не говоря уже о процедуринах каждая на неск тысяч строк и получишь представление о примерном обьеме массивного ынтырпрайза. Постгресс к сожалению там нет места. А все твои фантазии из разряда «ожидания — реальность»

И че, с чего ты взял что постгрес с этим не справится?

Что пора качать САП :)
Ты там заикался о распределенной сети закачки с разных айпишников. Озвучь свои мысли.

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

Ясно. Если будут вопросы/ответы по конструктивной части, то можешь оставлять в коментах. Можно прямо в блоге — я отвечу.

Ты тоже, если будут конструктивные замечания — обязательно пеши.

частенько, но явно не в случае правнения бесплатной субд, на которой студенты пишут свои курсачи и в большинстве своем забывают после выхода во взрослую жизнь, с топовой коммерческой субд. Ты сам то кого живьем чаще видел, ораклоидов или постгресников?

Почему это «явно не в случае»? Откуда такой вывод? У тебя помоему ентерпрайз головного мозга, «топовые комерческие БД», «поддержка», «крупные клиенты», бла-бла-бла.
По факту на примере поддержки массивов твои топовые БД всосали, и ты решил перепрыгнуть на мутную тему «популярности».

А админов постгреса мало потому что он простой, и в компаниях где он применяет с ним легко управляется админ эникейщик, или девопс какой, и не нужно департамента дбэев с тремя уровнями иерархии.

Откуда такой вывод? У тебя помоему ентерпрайз головного мозга
 Ну так энтерпайз как раз основной потребитель СУБД больших субд. Нишу не энтерпрайзных СУБД давно прочно занимает мускул, что опять же видно по его рейтингу. А постгрес так, сбоку припеку. А ты упорно пытаешься опровергнуть очевидную истину, что оракл намного популярнее постгреса на притянутом за уши аргументе про стековерфлоу.
«поддержка»
ну раз ты уже поднял тему поддержки, как думаешь, что выберет человек, которому нужна СУБД для бизнеса — поддержку массивов, или техническую поддержку?
на примере поддержки массивов твои топовые БД всосали
 Ну, если для тебя данный синтаксический сахар имеет важное значение, то да, без постгреса тебе никуда.
и ты решил перепрыгнуть на мутную тему «популярности»
Конечно я понимаю, что миллионы мух не могут ошибаться, но популярность той или иной СУБД не приходит просто так.
А админов постгреса мало потому что он простой
Ораклоиды — это не только админы, но еще и толпы разработчиков. А если нужна простая база, то опять же, давно придумали мускул.
Ну так энтерпайз как раз основной потребитель СУБД больших субд. Нишу не энтерпрайзных СУБД давно прочно занимает мускул, что опять же видно по его рейтингу. А постгрес так, сбоку припеку. А ты упорно пытаешься опровергнуть очевидную истину, что оракл намного популярнее постгреса на притянутом за уши аргументе про стековерфлоу.
Энтерпрайз энтерпрайзу рознь, да я не спорю, в банках где тысячи индусов патогонно гужевым способом педалят 10летнейк давности ejb код оракл непревзойдет. Но сейчас идет становление компаний новой волны, которые благодаря инновациям агресивно вытесняют старых динозавров с рынка, и постгрес там более чем в почете.
ну раз ты уже поднял тему поддержки, как думаешь, что выберет человек, которому нужна СУБД для бизнеса — поддержку массивов, или техническую поддержку?
У постгреса в экосистеме вполне есть компании оказывающие поддержку, тут ты пролетел.
Ну, если для тебя данный синтаксический сахар имеет важное значение, то да, без постгреса тебе никуда.
Про синтаксический сахар — это твой высос из пальца
онечно я понимаю, что миллионы мух не могут ошибаться, но популярность той или иной СУБД не приходит просто так.
Да, она приходит с помощью или качества продукта или многомиллиардных вливаний в маркетинг, ну ты понял кто тут что использует в поединке оракл вс постгрес
Ораклоиды — это не только админы, но еще и толпы разработчиков. А если нужна простая база, то опять же, давно придумали мускул.
Отлично, в моей среде постгрес разработчиков больше чем оракл, ну и мскл сосет у постгреса во всех отношениях
10летнейк давности ejb код
десятилетней давности по оракловым меркам это еще весьма молодой код — ораклу то уже скоро 40 стукнет :)
Но сейчас идет становление компаний новой волны, которые благодаря инновациям агресивно вытесняют старых динозавров с рынка, и постгрес там более чем в почете.
Ну так я и не спорю, что к очередному съезду КПСС постгресс догонит и перегонит оракл, но речь идет о «сейчас».
это твой высос из пальца
Это объективная реальность РДБМС — можно либо искать по индексу, либо тупо перебирая все элементы (может ты еще какие то секретные способы знаешь, тогда делись). Кстати, если подобный финт ушами с массивами таки захочется провернуть в SQL Server (в оракл наверное тоже, точно не вкурсе) то можно запихнуть все что угодно в колонку типа XML. Тоже будет больно и долго.
ну ты понял кто тут что использует в поединке оракл вс постгрес
Это да, но интересно, кто что использует в поединке мускул vs простгрес, ибо даже в рейтинге стековерфлоу мускула в 5 раз больше.
десятилетней давности по оракловым меркам это еще весьма молодой код — ораклу то уже скоро 40 стукнет :)
Это типа предмет для гордости?
Ну так я и не спорю, что к очередному съезду КПСС постгресс догонит и перегонит оракл, но речь идет о «сейчас».
Ок, и что на счет «сейчас»?
Это объективная реальность РДБМС — можно либо искать по индексу, либо тупо перебирая все элементы (может ты еще какие то секретные способы знаешь, тогда делись).
Я не понял мысли, есть приведенная задача — искать по инвертированному индексу, я утверждаю что благодаря использованию масивов в постгре эта задача решается намного эфективнее там. Что не так, какие твои конкретные претензии?
Это да, но интересно, кто что использует в поединке мускул vs простгрес, ибо даже в рейтинге стековерфлоу мускула в 5 раз больше.
мскл типа всегда была частью комерческих компаний, так что тут тоже маркетинг замешан.
Это типа предмет для гордости?
нет, это просто очередная причина, почему оракл намного популярнее постгреса, не смотря на равные рейтинги доу.
Ок, и что на счет «сейчас»?
Сейчас оракл намного популярнее постгреса, если считать по количеству рыл, которые на нем работают.
Что не так, какие твои конкретные претензии?
Я так понимаю, задача стоит «для каждого слова вытащить весь список айдих документов и для каждой найти конкретные значения полей»?
Если так, то я вижу в твоем решении следующие грабли — в рдбмс хранение поля заранее неизвестной длинны (массив айдих) обычно сопряжено с дикой фрагметнацией памяти. Ну разве что если залить все данные сразу целиком и никогда не менять, и то не вегда помогает. Может конечно постгрес против этого таки изобрел какую-то серебрянную пулю, тут я не в курсе.
С другой стороны если построить индекс «многие ко многим», то данные по ключу будут храниться на соседних страницах, поэтому количество сиков будет логарифмически зависеть от размера массива, так что аццкого прироста производительности в постгресе для выборки всего массива не будет.
Ну а если захочется сделать точно так же, как в постгресе, то можно создать колонку типа XML.
Ты кстати реально разницу сравнивал, или теоретизируешь?
нет, это просто очередная причина, почему оракл намного популярнее постгреса, не смотря на равные рейтинги доу.
Не очередная, и не причина )) Постгрес в реинкарнации ингресса вполне ровесник оракла!
Сейчас оракл намного популярнее постгреса, если считать по количеству рыл, которые на нем работают.
По числу индусских админов протирающих штаны может быть, по числу программистов строящих на них системы, по числу юзеров обслуживаемых этими системами — глубокий нефакт
Если так, то я вижу в твоем решении следующие грабли — в рдбмс хранение поля заранее неизвестной длинны (массив айдих) обычно сопряжено с дикой фрагметнацией памяти. Ну разве что если залить все данные сразу целиком и никогда не менять, и то не вегда помогает. Может конечно постгрес против этого таки изобрел какую-то серебрянную пулю, тут я не в курсе.
Лол, или не дикой. У тебя большая часть диалектики ограничивается навешыванием высосанных из пальца ярлыков.
С другой стороны если построить индекс «многие ко многим», то данные по ключу будут храниться на соседних страницах
Между чем и чем ты собираешься строить индекс? И что это такое «индекс „многие ко многим“», проясни пожалуйста?
Ты кстати реально разницу сравнивал, или теоретизируешь?
Я теоретизирую, схема предложенная ТС очевидно сосет у моего подхода. В чем заключается твой подход я пока не понял.
Лол, или не дикой.
Обоснуй.
В чем заключается твой подход я пока не понял.
Я не совсем 100% уверен в чем заключается подход ТС но мой подход:
Таблицы Слова (Ключ слово+ айди слова), Индекс (ключ айди слова+ айди документа), Документы (Ключ айди документа, поля -поля документа)
Выборка возможно будет на какие то проценты медленнее, чем такая же в постгресе, но за то можно модифицировать лист слов и документов не перстраивая индексы после каждой второй модификации.
UPD. А удаление документа в твоей схеме будет вообще забавным развлечением.
Обоснуй.
Та нет, это ты обоснуй, ты же сделал утверждение про большую фрагментацию в случае массива, мне как раз наоборот кажется что натурально они будут ложится одним непрерывным блоком на диск.
Таблицы Слова (Ключ слово+ айди слова), Индекс (ключ айди слова+ айди документа), Документы (Ключ айди документа, поля -поля документа)
Твой индекс в первых будет занимать значительно больше места, т.к. во первых на каждую пару документ слово я храню только айди документа в массиве, а ты еще и айди слова, во вторых в твоей таблице будет в 750 раз больше строк, а на каждую строку в базах обычно есть большой оверхед по месту. Во вторых у тебя нету никакой гарантии что строки будут на диске лежать рядом, а скорее всего наоборот, и поэтому на прочтение каждой строки таблицы у тебя будет уходить отдельное чтение с диска, а у меня массив считается одним чтением. Так что разница в скорости может будет в сотни и тысячи раз.
о за то можно модифицировать лист слов и документов не перстраивая индексы после каждой второй модификации.
А зачем именно мне перестраивать индекс?
UPD. А удаление документа в твоей схеме будет вообще забавным развлечением.
обоснуй почему
натурально они будут ложится одним непрерывным блоком на диск
Это только в том случае, если как я написал
разве что если залить все данные сразу целиком и никогда не менять
А что произойдет непрерывно уложенным на диск блоком, если ты туда захочешь добавить еще один айди где-то посредине?
Твой индекс в первых будет занимать значительно больше места
Это да — это цена за возможность нормально модифицировать данные.
а на каждую строку в базах обычно есть большой оверхед по месту.
Ну прямо уж таки большой — в SQL сервере кроме, собственно данных, нужно будет хранить дополнительно где-то log(размер страницы/размер строки) страниц.
Во вторых у тебя нету никакой гарантии что строки будут на диске лежать рядом
Не знаю, как там у вас в постгресе, но в SQL сервере строки кластерного индекса относящиеся к одному ключу лежат на одной странице, ну или если не влазят в одну, но в соседних.
на прочтение каждой строки таблицы у тебя будет уходить отдельное чтение с диска
Опять же, может посгрес и читает строки по одной с диска, а взрослая СУБД SQL сервер читает всю страницу целиком.
А зачем именно мне перестраивать индекс?
Если постгрес настолько туп что не хранит рядом одинаковые значения ключа, то действительно индекс перестраивать не нужно.
обоснуй почему
Потому, что чтобы удалить конкретный айди документа нужно просмотреть запись для каждого слова, а потом в массиве просмотреть каждую запись (ну на самом деле не каждую, но время все равно линейное)
Потом эту запись удалить. Образовавшиеся дырки дадут фрагментацию.
Это только в том случае, если как я написал
А если не в том цлучае как ты написал?
А что произойдет непрерывно уложенным на диск блоком, если ты туда захочешь добавить еще один айди где-то посредине?
массив прочитается одним блоком, айди вставится, и опять запишется одним блоком.
то да — это цена за возможность нормально модифицировать данные.
А в чем ненормальность в случае постгре и массивом?
Не знаю, как там у вас в постгресе, но в SQL сервере строки кластерного индекса относящиеся к одному ключу лежат на одной странице, ну или если не влазят в одну, но в соседних.
Опять же, может посгрес и читает строки по одной с диска, а взрослая СУБД SQL сервер читает всю страницу целиком.
Если постгрес настолько туп что не хранит рядом одинаковые значения ключа, то действительно индекс перестраивать не нужно
Ну ты как бы про класстерные индексы ничего не писал, и это сильно другая тема, и даже сам МС не рекомендует их использовать в часто изменяемых таблицах:
Clustered indexes are not a good choice for:
Columns that undergo frequent changes
This results in the entire row moving (because SQL Server must keep the data values of a row in physical order). This is an important consideration in high-volume transaction processing systems where data tends to be volatile.
technet.microsoft.com/...(v=sql.80).aspx
Потому, что чтобы удалить конкретный айди документа нужно просмотреть запись для каждого слова, а потом в массиве просмотреть каждую запись (ну на самом деле не каждую, но время все равно линейное)
Потом эту запись удалить. Образовавшиеся дырки дадут фрагментацию.
Ну это если массив не сомкнется после удаления элемента
массив прочитается одним блоком, айди вставится, и опять запишется одним блоком
 Но запишется он одним блоком в другое место, т.к. на старое место он уже не влезет, а на месте, где он был раньше образуется дырка, так ведь?
А в чем ненормальность в случае постгре и массивом?
Просмотр всех 5ТБ данных для удаления всего одного элемента мне видится ненормальным.
Ну ты как бы про класстерные индексы ничего не писал
 Да, я уже по дороге сообразил, что не уточнил насчет кластерного индекса, поскольку для SQL Server это очевидное решение.
МС не рекомендует их использовать в часто изменяемых таблицах
Не в таблицах, а колонках
Columns that undergo frequent changes
, т.е. если меняется ключ какой-то записи.
Ну это если массив не сомкнется после удаления элемента
Сомкнется, это в смысле все элементы после дырки сдвинутся влево? Тогда образуется дырка между концом массива и следующим массивом.
Но запишется он одним блоком в другое место, т.к. на старое место он уже не влезет, а на месте, где он был раньше образуется дырка, так ведь?
Так ведь, потом на это место опять запишутся данные
Просмотр всех 5ТБ данных для удаления всего одного элемента мне видится ненормальным.
5 террабайт это типа индекс на почти триллионов документов, тем более если айдишники отсортированы то поиск происходит за логарифмическое время
Не в таблицах, а колонках
Columns that undergo frequent changes
, т.е. если меняется ключ какой-то записи.
НУ это относится и к вставкам тоже, если тебе нужно вставить новую запись в таблицу, а происходить это у тебя будет в 750 раз чаще чем в случае с моими массивами, сиквелу прийдется двигать все строки на странице, при этом он залочит для этого страницу, а постгрес будет лочить только колонку в определенной строке где лежит массив
Сомкнется, это в смысле все элементы после дырки сдвинутся влево? Тогда образуется дырка между концом массива и следующим массивом.
Ну в постгре оно все равно после этого в другое место запишется, так как там полноценный МВЦЦ в отличие от мс скл, которому все блочить приходится, так что это не имеет значение
Так ведь, потом на это место опять запишутся данные
Или не запишутся, если дырка будет достаточно мала. Можно записывать данные в ближайшую дырку, все что не влезло в следующую и т.д. Тогда получится фрагментация. Или как оно будет действовать?
тем более если айдишники отсортированы то поиск происходит за логарифмическое время
 Во первых тебе все равно надо просмотреть все слова, а во вторых тогда вставка будет проходить за линейное время.
прийдется двигать все строки на странице

В данном случае, если ты добавляешь новые документы в индекс, то айди у них будет больший, чем у существующих документов, так что двигать в большинстве случаев никого не придется.
при этом он залочит для этого страницу
Если у тебя система будет настолько активно вставлять и читать, что блокировка страниц будет превращаться в проблему, то read committed snapshot может спасти отца русской демократии. Или придется раскошелиться на оракл, в котором блокировок нет.
а постгрес будет лочить только колонку в определенной строке где лежит массив
Если мы говорим о большом количестве документов, то не факт, что ячейка с массивом будет меньше, чем страница.
Кстати, если рассматривать блокировку как средство обеспечения целостности данных, то в твоем неблокировочном решении можно спокойно удалить документ, а ссылки на него останутся.
ли не запишутся, если дырка будет достаточно мала. Можно записывать данные в ближайшую дырку, все что не влезло в следующую и т.д. Тогда получится фрагментация. Или как оно будет действовать?
Это фишка всех МВЦЦ баз, они пишут все изменения на новое место, а потом специальный бекграунд процесс все подзачищает и дефрагментирует
Во первых тебе все равно надо просмотреть все слова, а во вторых тогда вставка будет проходить за линейное время.
Можешь обьяснить зачем мне смотреть все слова? Но вставка да, будет линейна, за счет двигания элементов массива, но я думаю это типа суперэфективная операция
В данном случае, если ты добавляешь новые документы в индекс, то айди у них будет больший, чем у существующих документов, так что двигать в большинстве случаев никого не придется.
Дык кластерный индекс у тебя должен быть на айди слов а не документов, и среди новых пар слово, документ будет много старых слов
Если у тебя система будет настолько активно вставлять и читать, что блокировка страниц будет превращаться в проблему, то read committed snapshot может спасти отца русской демократии.
Читаться не обязательно, именно конкурентные вставки в одну страницу
Или придется раскошелиться на оракл, в котором блокировок нет.
Лол, или перейти на бесплатный постгрес
Если мы говорим о большом количестве документов, то не факт, что ячейка с массивом будет меньше, чем страница.
Не факт, но будет большое число колонок где факт, и там будет серьезный выигрыш
Кстати, если рассматривать блокировку как средство обеспечения целостности данных, то в твоем неблокировочном решении можно спокойно удалить документ, а ссылки на него останутся.
Нельзя, почитай что такое MVCC уже
Можешь обьяснить зачем мне смотреть все слова?
Если у тебя есть список слов, а каждому слову есть массив айдишников документов и тебе допустим надо удалить айдишник номер 42 из всех слов. Как ты определишь, из каких именно массивов надо удалять, не просмотрев их все?
Дык кластерный индекс у тебя должен быть на айди слов а не документов
Индекс на пару «слово+документ» именно в таком порядке. По индексу первым найдется слово, а среди айдишников документов к этому слову новый будет максимальным. Двигать придется, если в странице больше одного слова, и то немного, поскольку слов очевидно будет меньше, чем документов.
Нельзя, почитай что такое MVCC уже
А ты почитай, что такое
read committed snapshot
, о котором я писал выше и увидишь, что это и есть MVCC, который в MS SQL уже почти 10 лет. Только я не совсем понял, как он может помочь сохранить целостность данных при отсутствии внешнего ключа.
Если у тебя есть список слов, а каждому слову есть массив айдишников документов и тебе допустим надо удалить айдишник номер 42 из всех слов. Как ты определишь, из каких именно массивов надо удалять, не просмотрев их все?
Если нужно удалять то можно держать индекс — докайди — список слов.
Индекс на пару «слово+документ» именно в таком порядке. По индексу первым найдется слово, а среди айдишников документов к этому слову новый будет максимальным. Двигать придется, если в странице больше одного слова, и то немного, поскольку слов очевидно будет меньше, чем документов.
это неочевидно, я тут на досуге википедию распарсил, там половина уникальных слов даже после стемминга, т.е. у тебя именно будет очень много слов с одним докайди, и на странице наверняка будет много слов.
Если нужно удалять то можно держать индекс — докайди — список слов.
Ну наверное тогда надо не список слов, а список айди слов — иначе данный индекс будет совершенно ненормальных размеров. А если завести айди слов, нужно будет еще один индекс «слово-его айди». Думаешь в сумме это все будет занимать меньше места, чем решение SQL Server?
это неочевидно, я тут на досуге википедию распарсил
Если у тебя слов больше, чем документов, то скорее всего это значит просто мало документов — слов, я думаю, должно быть порядка пары сот тысяч в одном языке.
Ну наверное тогда надо не список слов, а список айди слов — иначе данный индекс будет совершенно ненормальных размеров. А если завести айди слов, нужно будет еще один индекс «слово-его айди». Думаешь в сумме это все будет занимать меньше места, чем решение SQL Server?
Удаление докуемнтов это типа уже дополнительное условие, с ним может и будет одинаковые размеры приблизительно.
Если у тебя слов больше, чем документов, то скорее всего это значит просто мало документов — слов, я думаю, должно быть порядка пары сот тысяч в одном языке.
Ну может в языке и пара сотен тыс., но есть еще всякие узкие термины, имена, даты, цифры разные. Мои данные такие: я распарсил 10 самых популярных википедий, это 100ГБ текста, 10 млн статей, и получилось 20 млн лексем.
А ты почитай, что такое
read committed snapshot
, о котором я писал выше и увидишь, что это и есть MVCC, который в MS SQL уже почти 10 лет.
Как я уже написал рид коммитед снапшот тебе не поможет если у тебя много конкурентных вставок, будет блокировка страницы. Он помогает только при чтении когда одна вставка.
Только я не совсем понял, как он может помочь сохранить целостность данных при отсутствии внешнего ключа
Опиши сценарий когда целостность не будет соблюдаться
Как я уже написал рид коммитед снапшот тебе не поможет если у тебя много конкурентных вставок, будет блокировка страницы. Он помогает только при чтении когда одна вставка.
По моему не должен
msdn.microsoft.com/...y/ms173763.aspx
If READ_COMMITTED_SNAPSHOT is set to ON, the Database Engine uses row versioning to present each statement with a transactionally consistent snapshot of the data as it existed at the start of the statement. Locks are not used to protect the data from updates by other transactions.
Хотя надо перепроверить.
Опиши сценарий когда целостность не будет соблюдаться
Например у тебя есть докайди 100 в таблице доков и куча ссылок на него в колонке с массивами. Допустим ты удаляешь этот докайди. Что будет с сылками в колонке с массивами? Или можно в постгресе задать какой-то хитрый внешний ключ?
По моему не должен
Ну это может не применительно к кластерному индексу. Сложно представить как два процесса будут одновременно двигать одни и те же данные на странице при вставке новой строки.
Например у тебя есть докайди 100 в таблице доков и куча ссылок на него в колонке с массивами. Допустим ты удаляешь этот докайди. Что будет с сылками в колонке с массивами? Или можно в постгресе задать какой-то хитрый внешний ключ?
Их нужно ручками удалять.

Зачем одновременно? Раздать каждому процессу по своему снепшоту, а потом двигать их по очереди.

Их нужно ручками удалять.
Ну, если в SQL сервере тоже похерить целостность данных, то и его можно разогнать побыстрее без всяких блокировок.
Зачем одновременно? Раздать каждому процессу по своему снепшоту, а потом двигать их по очереди.
А потом мерджить?
Ну, если в SQL сервере тоже похерить целостность данных, то и его можно разогнать побыстрее без всяких блокировок.
Как?
А потом мерджить?
Дабы не мудрстовать лукаво, завтра как проснется наш базовик-затейник, спрошу у него.
Как?
Самый радикальный способ устроить полный коммунизьм в SQL Server без всяких блокировок — это объявить set transaction isolation level read uncommitted
будет лочить только колонку в определенной строке где лежит массив
Кстати, если у тебя массив в какой-то момент разрастется до немеряных размеров, тебе для вставки придется его считать весь целиком в память, вставить элемент на нужное место а потом записать обратно?
Кстати, если у тебя массив в какой-то момент разрастется до немеряных размеров, тебе для вставки придется его считать весь целиком в память, вставить элемент на нужное место а потом записать обратно?
Массив не разрастется до невероятных размеров, верхняя граница будет например количество доков по слову hello в выдаче гугла — 250млн айдишников, или 1ГБ. Но если дорасту до уровня гугла, то легко на всю эту тему накрутить шардинг, ключ будет не слово, а например слово + hash(докайди) % количество шардов, и большой массив распадется на сколько скажешь маленьких.

Я если что все это на работе программирую, у меня в индексе 90 миллиардов документов, размер компрессированного snappy индекса 80 террабайт, и все отлично летает.

Нет, у бинга наверное побольше в раз тыщю индекс

та да, и выдача в 100 раз меньше чем у гугла

Это мамонты прошлого десятилетия, я верю в v-search.org

Ну, даже если там будет пару сот мегабайт в массиве, то при добавлении постгресс их считает, добавит а потом запишет обратно? SQL сервер при добавлении чего-то поковыряет в своей 8 килобайтной странице и вредких случаях сделает сплит индекса.

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

Для этого как я уже написал есть шардинг.
Ну, я так понимаю, изначально разговор шел о том, чтобы сравнить постгрес и SQL сервер решения как есть. Понятно, что поверх много чего можно наворотить.
то популярные слова будут раскиданы на куче страниц
Задача изначально вроде стояла оценить эффективность поиска по конкретному слову.
у, я так понимаю, изначально разговор шел о том, чтобы сравнить постгрес и SQL сервер решения как есть. Понятно, что поверх много чего можно наворотить.
поверх sql server мою идею с шардингом нельзя.
Задача изначально вроде стояла оценить эффективность поиска по конкретному слову.
Ну да, ты написал что у слова может быть 200 мегабайт док айдишников, очевидно тогда твой кластерный индекс для этого слова будет расскидан на 400(айди слова + айди док) мегабайт / 4кб = 100к страниц, и на каждую страницу может понадобиться делать вжик по диску, что займет наверное пару часов. Клевый поисковичек.
поверх sql server мою идею с шардингом нельзя
не обязательно даже поверх — возможность шардига встроена прямо в движок в виде table partitioning.
и на каждую страницу может понадобиться делать вжик по диску, что займет наверное пару часов.
У тебя какие-то дикие предрассудки по поводу SQL сервера — вот только что дернул 100МБ данных из кластерного индекса за 17 секунд на стареньком тестовом серваке без какого либо дополнительного тюнинга. Потому как во-первых, он страницы не раскидывает, а старается хранить рядом, и даже если в какой то момент нелегкая судьба раскидает их по разным углам диска, то можно сделать ребилд индекс, и снова наступит счастье. А во-вторых, ничто не мешает подобрать оптимальный размер страницы.
не обязательно даже поверх — возможность шардига встроена прямо в движок в виде table partitioning.
Ну расскажи какую именно схему партишионинга ты предлагаешь в контексте данной задачи, и чего ты пытаешься добиться?
У тебя какие-то дикие предрассудки по поводу SQL сервера — вот только что дернул 100МБ данных из кластерного индекса за 17 секунд на стареньком тестовом серваке без какого либо дополнительного тюнинга.
17сек что бы прочитать 100мб с диска это типа совсем не круто, проблемы фрагментации уже здесь дают о себе знать, какой поисковик выдает результат с латентностью в 17 секунд? Ну и я не знаю особенностей как ты там свой индекс создавал. Может у тебя айдишники монотонно росли и все записывалось на пустой диск, а потом еще и закешировалось в памяти.
Потому как во-первых, он страницы не раскидывает, а старается хранить рядом,
«он» про страницы и как ону лежат ничего не знает, этим занимается ФС.
А во-вторых, ничто не мешает подобрать оптимальный размер страницы.
Вот тока облом, нтфс не поддерживает размер страницы больше 64к.
Ну расскажи какую именно схему партишионинга ты предлагаешь в контексте данной задачи, и чего ты пытаешься добиться?
Ты написал, что твою идею с шардингом по ключу «слово+хэш докайди» нельзя сделать на SQL сервере. Ничто не мешает создать ключ «слово+хэш докайди» и сделать партишенинг по нему.
17сек что бы прочитать 100мб с диска это типа совсем не круто
Ясное дело не круто в индексе с фрагментацией 85% на дряхлом загруженном сервере. Просто я тебе порядок величин показываю, т.к. ты вообще про часы рассказывал.
какой поисковик выдает результат с латентностью в 17 секунд?
Ну, во первых поисковик не выдает клиенту сотни мегабайт данных, а во вторых есть туева хуча способов разогнать SQL сервер до приемлемой скорости.
Может у тебя айдишники монотонно росли и все записывалось на пустой диск, а потом еще и закешировалось в памяти.
В памяти точно не кэшировалось, а проблема монотонно растущих айдишников решается периодическим ребилдом индекса. Тем более, айдишники документов тоже растут монотонно, следовательно ребилдить индекс придется не так часто. Что касается пустого диска, думаю постгрес засранному диску тоже не обрадуется.
Ты написал, что твою идею с шардингом по ключу «слово+хэш докайди» нельзя сделать на SQL сервере. Ничто не мешает создать ключ «слово+хэш докайди» и сделать партишенинг по нему.
Ничто не мешает и доску к потолку прибить, тока нафига? В контексте обсуждаемого случая у тебя таблица уже распартишена на 4кб станицы по самое немогу. Еще раз спрашиваю, чего ты добиться пытаешься?
Ясное дело не круто в индексе с фрагментацией 85% на дряхлом загруженном сервере. Просто я тебе порядок величин показываю, т.к. ты вообще про часы рассказывал.
Это все эпитеты, неизвестный запрос, на неизвестном железе, на неизвестной таблице, неизвестного размера выполняется 17 сек, это ниачем и скорее антиреклама. Откуда взялись часы я тебе подробно описал, тебе что-то непонятно, есть какие то конкретные возражения к моему описанию?
Ну, во первых поисковик не выдает клиенту сотни мегабайт данных,
Но он их в зависимости от запроса вполне может быть должен проанализировать
а во вторых есть туева хуча способов разогнать SQL сервер до приемлемой скорости.
способы наверняка сертифицированные и подсказанные службой поддержки платинум партнера, раз ты в них так уверен?
В памяти точно не кэшировалось
Это ты выяснил конечно же с помощью гадания на ритуальных костях?
а проблема монотонно растущих айдишников решается периодическим ребилдом индекса
Я же уже тебе написал, физическим размещением страниц занята ФС а не скл сервер, и у тебя никогда не будет никакой гарантии что страницы твоего кластерного индекса лежат рядом.
ем более, айдишники документов тоже растут монотонно, следовательно ребилдить индекс придется не так часто. Ч
Ты точно не читатель, я тебе уже писал, что первой компонентой твоего кластерного индекса будет айди слова, а не документа, которые при вставке совсем не монотонны.
Что касается пустого диска, думаю постгрес засранному диску тоже не обрадуется.
Но мой подход — инвертированный индекс и большие страницы сильно уменьшит фрагменрацию, при размере страницы скажем 4мб — в тысячу раз по сравнению с твоим подходом.
уже распартишена на 4кб станицы по самое немогу
Партишенинг подразумевает физическое разделение файлов, т.е. партишен можно положить на отдельный файл, а то и диск или даже сервер.
Еще раз спрашиваю, чего ты добиться пытаешься?
Если много чтений, можно читать одновременно с разных дисков.
А ты своим шардингом каких целей добиваешься?
есть какие то конкретные возражения к моему описанию?
Судя по твоему описанию, если на 100к страниц нужно делать на каждую вжик по диску (что возможно только в том случае, что диск фрагментирован настолько, что невозможно разместить даже 2 куска по 4 кб последовательно) то для того, чтобы это читалось пару часов у тебя каждое чтение должно занимать 0.07сек. Ты похоже в своих теоретических расчетах используешь какой то полупосыпавшийся диск 3200RPM
способы наверняка сертифицированные и подсказанные службой поддержки платинум партнера, раз ты в них так уверен?
Хорош пертосянить, можно подумать, у твоего постгреса нет никаких настроек оптимизации и от железа на котором он работает его производительность никак не зависит.
Это ты выяснил конечно же с помощью гадания на ритуальных костях?
Запрос который я сделал не имеет практического смысла, следовательно до этого никогда не выполнялся, сама таблица используется не часто, а у сервера полно других нужных запросов, чтобы пихать в кэш. Впрочем, если ты сомневаешься в этом настолько, что даже кушать не можешь, то могу специально поковыряться в профайлере.
и у тебя никогда не будет никакой гарантии что страницы твоего кластерного индекса лежат рядом
Гарантию, конечно может дать только страховой полис, но если у тебя на диске достаточно места и он не сильно фрагментирован, и SQL сервер при ребилде индекса скажет ФС «дай мне 100500 мегабайт», то с какого ФС будет раскидывать их по всему диску?
Ты точно не читатель,
Ты тоже не читатель, потому как я написал, что
ребилдить индекс придется не так часто
Если бы ключом был айди документа, то индекс не пришлось бы ребилдить вообще. Я правда исходил из предположения, что новые слова появляются значительно реже, чем новые документы, твоем примере с википедией сплитов страниц конечно будет намного больше.
Но мой подход — инвертированный индекс и большие страницы сильно уменьшит фрагменрацию, при размере страницы скажем 4мб — в тысячу раз по сравнению с твоим подходом.
За то объем данных, который тебе придется записать/стереть на диске для того, чтобы получить 100МБ в одном поле массива, будет приблительно в десятки тысяч раз больше, что вызовет соответсвенно куда большую фрагментацию диска. Кстати, в постгрессе МВЦЦ только блокировки разруливает, или еще и дефрагментатором диска на пол-ставки подрабатывает?
Партишенинг подразумевает физическое разделение файлов, т.е. партишен можно положить на отдельный файл, а то и диск или даже сервер.
Партишнинг ничего такого не подразумевает, это просто абстракция, под которой может быть что хочешь.
Если много чтений, можно читать одновременно с разных дисков.
А ты своим шардингом каких целей добиваешься?
Мой шардинг нужен для того что бы не оперировать 100МБ массивом при вставке, а только парой мегабайт шарда.
то для того, чтобы это читалось пару часов у тебя каждое чтение должно занимать 0.07сек. Ты похоже в своих теоретических расчетах используешь какой то полупосыпавшийся диск 3200RPM
Ок, пусть будет не 0.07 сек, а 0.007 сек, что вполне реалистичное число для современных винтов, тогда твой поисковик будет выдавать результат с задержкой не пару часов, а 10 минут, что все равно оборжака.
орош пертосянить, можно подумать, у твоего постгреса нет никаких настроек оптимизации и от железа на котором он работает его производительность никак не зависит.
Есть конечно, но я не сильно разбираюсь как они могут помочь в решении данной задачи, и помалкиваю по этому поводу, в отличие от.
Запрос который я сделал не имеет практического смысла, следовательно до этого никогда не выполнялся, сама таблица используется не часто, а у сервера полно других нужных запросов, чтобы пихать в кэш. Впрочем, если ты сомневаешься в этом настолько, что даже кушать не можешь, то могу специально поковыряться в профайлере.
Да, со вчерашнего дня ничего не ел, попрофайль пожалуйста кеш файловой системы для меня?
Ты тоже не читатель, потому как я написал, что
ребилдить индекс придется не так часто
А как твое нечасто относится к обсуждаемой проблеме дефрагментации файловой системы? И откуда ты взял что именно «не часто»?
Я правда исходил из предположения, что новые слова появляются значительно реже, чем новые документы, твоем примере с википедией сплитов страниц конечно будет намного больше.
Дык наоборот если у тебя все слова старые, тебе прийдется постоянно вставлять пары слово, документ в самую середину твоего кластерного индекса, и сплитов будет больше чем.
За то объем данных, который тебе придется записать/стереть на диске для того, чтобы получить 100МБ в одном поле массива, будет приблительно в десятки тысяч раз больше,
Больше, но благодаря шардингу не 100МБ
что вызовет соответсвенно куда большую фрагментацию диска
Та нет, в моем примере наоборот все данные из массива будут гарантировано ложится в одном месте на диске.
Кстати, в постгрессе МВЦЦ только блокировки разруливает, или еще и дефрагментатором диска на пол-ставки подрабатывает?
Не разруливает, поэтому умные дяди и используют описанный мной подход что бы получить гарантированное время чтения
Партишнинг ничего такого не подразумевает, это просто абстракция, под которой может быть что хочешь.
ХЗ, может в постгресе это просто абстакция, а SQL сервере в основном для этого и испольуется — для распихивания больших таблиц по разным файлам.
Мой шардинг нужен для того что бы не оперировать 100МБ массивом при вставке, а только парой мегабайт шарда.
Если я правильно понял, ты имеешь в виду хранить массив не в одной колонке а кусками в паре десятков колонок? Тогда соответсвенно он у тебя и будет читаться кусками с разных мест диска.
0.07 сек, а 0.007 сек, что вполне реалистичное число для современных винтов
Это с учетом кэша?
тогда твой поисковик будет выдавать результат с задержкой не пару часов, а 10 минут
Если бы это был мой поисковик, то я бы постарался избегать 100% фрагментации диска.
помалкиваю по этому поводу, в отличие от
А я за то помалкиваю про многочасовые чтения 100МВ с диска постгресом.
Да, со вчерашнего дня ничего не ел, попрофайль пожалуйста кеш файловой системы для меня?
Звыняй, могу отпрофайлить только личный кеш SQL сервера. Что касается кэша файловой системы, теоретические выкладки все еще в силе: откуда там возмется страница, которая не использовалась уже много месяцев?
А как твое нечасто относится к обсуждаемой проблеме дефрагментации файловой системы?
Потому как, если ребилдить индекс при наличии достаточного количества нефрагментированного места на диске, то ФС сложит туда страницы аккуратно друг за другом. Но поскольку ребилд индекса процесс относительно затратный, то лучше, чтобы он происходил нечасто.
Дык наоборот если у тебя все слова старые, тебе прийдется постоянно вставлять пары слово, документ в самую середину твоего кластерного индекса, и сплитов будет больше чем.
Если предположить, что все слова уже на месте и на каждое слово приходится в стреднем хотя бы несколько страниц айдишников, то большинство листовых страниц будет содержать отсортированные айдишники, которые относятся к одному слову, поэтому новый айдишник будет всегда добавляться в конец, соответсвенно сплитов листовых страниц почти не будет, будут просто добавляться новые страницы, а чтобы вызвать сплит узловых страниц, то листовых станиц надо будет напихать достаточно много.
Та нет, в моем примере наоборот все данные из массива будут гарантировано ложится в одном месте на диске.
Только в случае, если на диске найдется свободный кусок, достаточный для размещения массива целиком. А то в твоих расчетах относительно страниц SQL сервера дикая фрагментация рассматривается диска, как нечто само собой разумеющееся.
Если я правильно понял, ты имеешь в виду хранить массив не в одной колонке а кусками в паре десятков колонок? Тогда соответсвенно он у тебя и будет читаться кусками с разных мест диска.
Да, правда при размере страницы и шарда в 4МБ кусков будет в тысячу раз меньше чем в случае твоих страниц по 4к.
Это с учетом кэша?
Кеш при оценке латентности в худшем случае никто не учитывает, так как данные могут быть в кеше, а могут и не быть, и юзеру прийдется ждать.
Если бы это был мой поисковик, то я бы постарался избегать 100% фрагментации диска.
У тебя мало контроля над этим фактором в отличие от моего подхода. Ну пусть будет фрагментация не 100%, а 50%, ну даже 20% — время ожидания соответственно — 2 минуты, все равно оборжака.
А я за то помалкиваю про многочасовые чтения 100МВ с диска постгресом.
И правильно делаешь. 100МБ считывается за 3 секунды, для чего все и затевается.
Что касается кэша файловой системы, теоретические выкладки все еще в силе: откуда там возмется страница, которая не использовалась уже много месяцев?
Откуда мне знать что она не использовалась несколько месяцев?
Потому как, если ребилдить индекс при наличии достаточного количества нефрагментированного места на диске, то ФС сложит туда страницы аккуратно друг за другом. Но поскольку ребилд индекса процесс относительно затратный, то лучше, чтобы он происходил нечасто.
Но при большом трафике на запись к таблице у тебя фрагментация может достаточно быстро вырасти за пару часов, не?
Если предположить, что все слова уже на месте и на каждое слово приходится в стреднем хотя бы несколько страниц айдишников
Это голословное допущение которое может сильно не коррелировать с реальностью
Только в случае, если на диске найдется свободный кусок, достаточный для размещения массива целиком.
Та не обязательно целиком, я уже писал, у меня страницы по несколько мегабайт, пусть он будет даже разбит скажем на 10 кусков, это в 1000 раз лучше чем в твоем случае с страницами по 4кб.
50%, ну даже 20%
При таких уровнях фрагментации даже если ФС вдруг не сможет выделить 100МБ подряд, то выделит их достаточно большими кусками.
И правильно делаешь. 100МБ считывается за 3 секунды, для чего все и затевается.
Это ты не правильно делаешь — я тоже могу кидаться голословными утверждениями, что SQL Server на самом деле может (и пожалуй действительно может) прочитать 100МБ за 3 секунды, а ламерский постргес будет читать часами, но это не конструктивно.
Откуда мне знать что она не использовалась несколько месяцев?
Ну, теперь знаешь. Можно конечно для частоты экперимента нагенерить табличку новых гуидов и сделать к ней запрос.
Но при большом трафике на запись к таблице у тебя фрагментация может достаточно быстро вырасти за пару часов, не?
Ну, при достаточно большом трафике и полностью радномных ключах — наверное может. В таких случаях, кстати, не обязательно рубить с плеча и полностью ребилдить индекс — можно его дефрагментировать.
Это голословное допущение которое может сильно не коррелировать с реальностью
Если на каждое слово приходится не так много айдишников, то и проблема считать сразу много айдишников для конкретного слова не будет актуальной.
пусть он будет даже разбит скажем на 10 кусков, это в 1000 раз лучше чем в твоем случае с страницами по 4кб
при разумных значениях фрагметации диска, куски будут значительно больше, чем 4кб.
При таких уровнях фрагментации даже если ФС вдруг не сможет выделить 100МБ подряд, то выделит их достаточно большими кусками.
Ну вот я и сделал поправку на достаточно большие куски, уменьшил количество разбросанных страниц в 5 раз.
Это ты не правильно делаешь — я тоже могу кидаться голословными утверждениями, что SQL Server на самом деле может (и пожалуй действительно может) прочитать 100МБ за 3 секунды, а ламерский постргес будет читать часами, но это не конструктивно.
Только у меня не голословные утверждения, я уже несколько раз описал с помошью чего это достигается.
Ну, теперь знаешь. Можно конечно для частоты экперимента нагенерить табличку новых гуидов и сделать к ней запрос.
Та нет, не знаю, откуда мне знать?
Ну, при достаточно большом трафике и полностью радномных ключах — наверное может. В таких случаях, кстати, не обязательно рубить с плеча и полностью ребилдить индекс — можно его дефрагментировать.
Я где то писал про «рандомные» ключи?
Если на каждое слово приходится не так много айдишников, то и проблема считать сразу много айдишников для конкретного слова не будет актуальной.
То что большинство слов редко уникальны не означает что нету часто встречающихся слов, например hello, не?
при разумных значениях фрагметации диска, куски будут значительно больше, чем 4кб.
Ок, твоя архитектура опирается на слова «разумный» и «значительно», моя дает гарантированную задержку по времени ответа.
Ну вот я и сделал поправку на достаточно большие куски, уменьшил количество разбросанных страниц в 5 раз.
Куски по 20Кб — это все еще аццкая фрагментация.
Только у меня не голословные утверждения, я уже несколько раз описал с помошью чего это достигается.
Ну, общая идея примерно понятна, но когда доходит до конкретных цифр, то 2 часа превращаются в 2 минуты, хотя это тоже далеко от реальности.
Та нет, не знаю, откуда мне знать?
Лучший способ узнать — убедиться в этом самостоятельно.
Я где то писал про «рандомные» ключи?
Если ключи не радномные, а имеют некоторую закономерность в плане возрастания/убывания, то ситуация будет улучшаться или ухудшаться в зависимости от того, насколько существенна эта закономерность и насколько она соответсвует направлению индекса.
То что большинство слов редко уникальны не означает что нету часто встречающихся слов, например hello, не?
Ну так «хэло» будет иметь туеву хучу страниц, которые будут плодиться в закономерности, которую я описал, а всякие «череззаборногузадеришенко» в количесве одной штуки будут активно сплитить свои страницы, но за то для них не надо считывать много страниц сразу.
опирается на слова «разумный» и «значительно», моя дает гарантированную задержку по времени ответа
Если условия будут неразумные, например на диске нельзя разместить ни одного целого куска размером >=8КБ, как в твоих изначальных расчетах для SQL сервера, как ты добьешься гаранированной задержки по времени?
Куски по 20Кб — это все еще аццкая фрагментация.
Ну да, недостатки твоего подхода
Ну, общая идея примерно понятна, но когда доходит до конкретных цифр, то 2 часа превращаются в 2 минуты, хотя это тоже далеко от реальности.
2 часа эта была верхняя граница, под действием различных факторов которые ты слабо контролируешь оно может улучшиться, а может и нет
Лучший способ узнать — убедиться в этом самостоятельно.
Ну у меня нету девайса в хозяйстве на котором скл севрер запустился бы, использую только продвинутое и надежное ПО.
Если ключи не радномные, а имеют некоторую закономерность в плане возрастания/убывания, то ситуация будет улучшаться или ухудшаться в зависимости от того, насколько существенна эта закономерность и насколько она соответсвует направлению индекса.
Ок, в случае индексирования произвольного текстового корпуса из интернета ключи будут рандомные, и у тебя все будет плохо.
Ну так «хэло» будет иметь туеву хучу страниц, которые будут плодиться в закономерности, которую я описал, а всякие «череззаборногузадеришенко» в количесве одной штуки будут активно сплитить свои страницы, но за то для них не надо считывать много страниц сразу.
Я просто тебе отвечаю на утверждение что «проблема считать много айдишников для одного слова не будет актуальной». Для слова — hello будет, со всеми вытекающими в виде тормозов.
Если условия будут неразумные, например на диске нельзя разместить ни одного целого куска размером >=8КБ, как в твоих изначальных расчетах для SQL сервера, как ты добьешься гаранированной задержки по времени?
Еще раз, я использую большие размеры страниц ФС, у меня все куски цельные и по пару МБ.
2 часа эта была верхняя граница
Ну, почему же верхняя — на какой нибудь рабочей станции на базе старенького селерона можно и бОльшие тормоза получить, особенно если все свалить на один диск.
под действием различных факторов которые ты слабо контролируешь оно может улучшиться, а может и нет
По моему, подходящее железо не относится к разряду факторов, которые ты слабо контролируешь. Во всяком случае для промышленной разработки.
Ну у меня нету девайса в хозяйстве на котором скл севрер запустился бы, использую только продвинутое и надежное ПО.
SQL Azure Trial поможет твоему горю.
произвольного текстового корпуса из интернета ключи будут рандомные
Они будут иметь некоторую тенденцию к возрастанию, поскольку для распространенных слов они будут возрастать в рамках слова.
у тебя все будет плохо
Ну, во первых плохо будет до дефрагментации/ребилда, а во вторых плохо — это, как ты заметил, эпитет. Надо смотреть на цифры.
Для слова — hello будет, со всеми вытекающими в виде тормозов.
Для слова hello в перерывах между после ребилдами/дерагами, некоторые тормоза будут (может быть, если не повезет) только для нескольких новых страниц.
я использую большие размеры страниц ФС, у меня все куски цельные и по пару МБ.
 Т.е. если у тебя к слову всего один докайди, то ФС выделяет на него сразу пару МБ?
Ну, почему же верхняя — на какой нибудь рабочей станции на базе старенького селерона можно и бОльшие тормоза получить, особенно если все свалить на один диск.
Ну хорошо, уговорил, в твоем подходе все может быть еще хуже.
По моему, подходящее железо не относится к разряду факторов, которые ты слабо контролируешь. Во всяком случае для промышленной разработки.
Ну кроме железа — основной фактор — фрагментация, ну и то что мы обсуждали, как слова приходят в индек, че лежит в кеше, а еще представь себе некоторые компутеры обрабатывают больше одного паралельного запроса, и быстрый доступ к диску становится еще более критичным.
SQL Azure Trial поможет твоему горю.
И че, я там узнаю что за железо, и закешировались ли данные в памяти?
Они будут иметь некоторую тенденцию к возрастанию, поскольку для распространенных слов они будут возрастать в рамках слова.
О, еще один принцип твоего подхода к проектированию высокопроизводительных систем, полагаться на «некоторую тенденцию».
ДокАйди будут, а вот словоАйДи, которые стоят первой компонентой твоего кластерного индекса представь себе нет.
Ну, во первых плохо будет до дефрагментации/ребилда, а во вторых плохо — это, как ты заметил, эпитет. Надо смотреть на цифры.
Ну посмотрели уже, 17 секунд получилось..
Для слова hello в перерывах между после ребилдами/дерагами, некоторые тормоза будут (может быть, если не повезет) только для нескольких новых страниц.
Я тебе уже написал — ребилды и дефраги что бы ты под этим не понимал не дают тебе никих гарантий, это все спекуляции. Может будут а может нет.
Т.е. если у тебя к слову всего один докайди, то ФС выделяет на него сразу пару МБ?
Да, потом туда еще допишут другие массивы, нету никакой проблемы.
а еще представь себе некоторые компутеры обрабатывают больше одного паралельного запроса, и быстрый доступ к диску становится еще более критичным
Правда что ли? Надо будет мелкомягким про это открытие написать, может придумают в следующих версиях репликацию, кластеры и прочие способы эффективного параллельного доступа к данным.
И че, я там узнаю что за железо
Конкретный серийный номер железяки не узнаешь, а конкретные параметры — конечно, можешь даже подобрать, какие тебе больше подходят.
и закешировались ли данные в памяти?
Если ты создашь таблицу, запихнешь туда туеву хучу данных, то первый запрос к этой таблице соответсвенно в кэше ничего содержать не будет.
О, еще один принцип твоего подхода к проектированию высокопроизводительных систем, полагаться на «некоторую тенденцию».
А твой подход заключается в игнорировании очевидных тенденций?
а вот словоАйДи, которые стоят первой компонентой твоего кластерного индекса представь себе нет
слово+айди будет всегда вставлять в конец страницы, если для данного слова есть хотя бы одна страница. Представь, что докайди тоже не возрастают и почуствуй разницу.
Ну посмотрели уже, 17 секунд получилось
Это цифра, а не цифры.
ребилды и дефраги что бы ты под этим не понимал не дают тебе никих гарантий
Гарантий никто не дает — действительно может оказаться, что после ребилда допустим 0.1% страниц лежат на диске не в том порядке. Критично это или нет, каждый решает для себя.
Да, потом туда еще допишут другие массивы, нету никакой проблемы.
Т.е. если ФС выделит пару метров, туда пару тысяч слов запишут каждый по своему айди, потом, большая часть их сотрет, то кто все это дефрагментировать будет?
А считываться они, кстати, тоже будут одним куском?
Правда что ли? Надо будет мелкомягким про это открытие написать, может придумают в следующих версиях репликацию, кластеры и прочие способы эффективного параллельного доступа к данным.
Думаю мелкомягкие в курсе, и для своего полнотекстового движка в скл сервер как и для скажем бинга используют инвертированный индекс а не кластерный.
Конкретный серийный номер железяки не узнаешь, а конкретные параметры — конечно, можешь даже подобрать, какие тебе больше подходят.
Я думаю пас, предчувствую много телодвижений
Если ты создашь таблицу, запихнешь туда туеву хучу данных, то первый запрос к этой таблице соответсвенно в кэше ничего содержать не будет.
Так уж и ничего?
А твой подход заключается в игнорировании очевидных тенденций?
Это твой подход. Очевидная тенденция при создании поисковиков — использовать онвертированный индекс а не кластерный.
слово+айди будет всегда вставлять в конец страницы, если для данного слова есть хотя бы одна страница. Представь, что докайди тоже не возрастают и почуствуй разницу.
Это полная ерунда. Если есть одна запись уже для слова, которая в середине страницы, то следующая запись для этого слова приземлится точно в середину страницы а не в конец
Гарантий никто не дает — действительно может оказаться, что после ребилда допустим 0.1% страниц лежат на диске не в том порядке. Критично это или нет, каждый решает для себя.
А может и 20%, и 50%.
Т.е. если ФС выделит пару метров, туда пару тысяч слов запишут каждый по своему айди, потом, большая часть их сотрет, то кто все это дефрагментировать будет?
А считываться они, кстати, тоже будут одним куском?
Дефрагнентиоровать будет постгресовский автовакуум. Считываться массив докайди для одного слова будет одним куском с поправкой на шардинг, да.
для скажем бинга используют инвертированный индекс а не кластерный
только сомневаюсь, что пихают его в постгрес в поле типа массив.
Так уж и ничего?
В кэше sql server-а точно ничего, а кэширует ли ФС данные, которые еще не прочитала, честно говоря не знаю. В любом случае, количество physical reads можно посмотреть.
Если есть одна запись уже для слова
Ты опять не читатель — не запись, а страница. Т.е. Если есть хотя бы одна страница целиком состоящая из докайди для этого слова.
А может и 20%, и 50%.
Тогда это уже вопрос к руководству криворукого базоида.
Дефрагнентиоровать будет постгресовский автовакуум.
Вот кстати, что постгрес пишет про этот автовакум
www.postgresql.org/...-vacuuming.html
The standard form of VACUUM removes dead row versions in tables and indexes and marks the space available for future reuse. However, it will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free and an exclusive table lock can be easily obtained. In contrast, VACUUM FULL actively compacts tables by writing a complete new version of the table file with no dead space. This minimizes the size of the table, but can take a long time. It also requires extra disk space for the new copy of the table, until the operation completes.
Т.е. для дефрагментации надо всего то ничего — переписать всю таблицу на новое место целиком.
только сомневаюсь, что пихают его в постгрес в поле типа массив.
Ну пихают в другие базы, которые принципиально используют похожий механизм как и у постгреса, и что дальше?
В кэше sql server-а точно ничего, а кэширует ли ФС данные, которые еще не прочитала, честно говоря не знаю.
А я думаю не точно

В любом случае, количество physical reads можно посмотреть.
посмотри, мне недосуг
Ты опять не читатель — не запись, а страница. Т.е. Если есть хотя бы одна страница целиком состоящая из докайди для этого слова.
Цитирую дословно что ты там понаписал: «слово+айди будет всегда вставлять в конец страницы, если для данного слова есть хотя бы одна страница. » И где там «страница целиком состоящая из докайди.»? Может таки ты теперь уже сертифицированный нечитатель?
Тогда это уже вопрос к руководству криворукого базоида.
Или кровость скл сервера
Т.е. для дефрагментации надо всего то ничего — переписать всю таблицу на новое место целиком.
А как из этого следует что обычный вакуум не делает дефрагментации? Они сами в докe пишут что его хватает и он лучше чем полный автовакуум для таблиц с большим трафиком на запись? «Thus, moderately-frequent standard VACUUM runs are a better approach than infrequent VACUUM FULL runs for maintaining heavily-updated tables.»
похожий механизм как и у постгреса, и что дальше?
Пытаюсь выяснить, насколько концепция обратного индекса соответсвует его, на мой взгяд, неочевидной реализации через поле типа массив.
посмотри, мне недосуг
Та мне не жалко посмотреть, но ты ж опять скажешь, откуда я знаю, я сам не видел.
И где там «страница целиком состоящая из докайди.»?
А где там страница=запись?
Может таки ты теперь уже сертифицированный нечитатель?
По сути вопроса есть какие то возражения?
Или кровость скл сервера
Ну, так можно сказать, что если ты на заправке залил дизель вместо бензина и у тебя двигло навернулось, то это кривая машина.
А как из этого следует что обычный вакуум не делает дефрагментации?
Из этого?
However, it will not return the space to the operating system, except in the special case
его хватает и он лучше чем полный автовакуум для таблиц с большим трафиком на запись?
Они не пишут, что его хватает, они пишут, что это
better approach
, с чем я собственно согласен — делать полный вакум с переписыванием целой таблицы в пару гигабайт, при том, что в процессе переписывания туда будет пару (десятков) тысяч инсертов/апдейтов, мне видится исключительно хреновой затеей.
Пытаюсь выяснить, насколько концепция обратного индекса соответсвует его, на мой взгяд, неочевидной реализации через поле типа массив.
Ты выбрал очень обходной путь
Та мне не жалко посмотреть, но ты ж опять скажешь, откуда я знаю, я сам не видел.
Ну да, таков жестокий мир, в нем куча балаболов
А где там страница=запись?
А где я писал что страница=запись?
По сути вопроса есть какие то возражения?
Это у тебя по сути возражений нету, я тебе обьяснил что у тебя таки будет дофига вставок в середину страницы, если есть одна запись в середине страницы для слова, и пришла другая для этого же слова. Ты это проигнорировал, и попытался зачем то переключится на вариант когда данные для слова занимают всю страницу, при этом как то по диbильномy обьяснив свою мысль.
Ну, так можно сказать, что если ты на заправке залил дизель вместо бензина и у тебя двигло навернулось, то это кривая машина.
Ну или я залил таки бензин а машина таки кривая, такое ведь тоже может быть?
Из этого?
И где там что вакуум не делает дефрагментацию? Опять фантазируешь?
Они не пишут, что его хватает, они пишут, что это
better approach
Да, если А лучше Б, то видимо Б совсем не обязателен, и А хватает.
с чем я собственно согласен — делать полный вакум с переписыванием целой таблицы в пару гигабайт, при том, что в процессе переписывания туда будет пару (десятков) тысяч инсертов/апдейтов, мне видится исключительно хреновой затеей.
Лол, ты же тут активно пропагандировал перестраивать кластерный индекс, что именно это и делает.
А где я писал что страница=запись?
Ты свои аргументы приводил исходя из этого предположения.
Ты это проигнорировал, и попытался зачем то переключится на вариант когда данные для слова занимают всю страницу
 Я не переключился, я это и имел в виду изначально. К этому варианту есть претензии?
Ну или я залил таки бензин а машина таки кривая, такое ведь тоже может быть?
Может, но сперва надо залить бензин, а потом, если машина таки не поедет, предъявлять претензии.
И где там что вакуум не делает дефрагментацию?
Меня больше интересует, где там что вакум делает дефрагментацию. Дефрагментация по идее должна освобождать место, не?
Опять фантазируешь?
Наоборот, активно пытаюсь выяснить, действительно ли вакум работает еще и дефрагом на пол-ставки, или это ты фантазируешь.
Да, если А лучше Б, то видимо Б совсем не обязателен, и А хватает.
Ну да, большинство СУБД будет даватьприемлемую производительность даже при относительно большой фрагментации, так что при правильно построенной таблице без дефрагментации можно обойдись.
Лол, ты же тут активно пропагандировал перестраивать кластерный индекс, что именно это и делает.
Кластерном индексе каждый момент времени переписывается одна страница, соответсвенно разнуливать нужно только ее модификации.
Ты свои аргументы приводил исходя из этого предположения.
Опять мимо
Я не переключился, я это и имел в виду изначально. К этому варианту есть претензии?
В плане вставки данных для часто встречаемого слова в индекс нет, но что это меняет если есть 100500 других кейсов когда все будет не так хорошо?
Может, но сперва надо залить бензин, а потом, если машина таки не поедет, предъявлять претензии.
Ну вот у тебя уже не поехала, 17сек и все такое.
Меня больше интересует, где там что вакум делает дефрагментацию. Дефрагментация по идее должна освобождать место, не?
А он и освобождает место, просто не отдает его ФС, а использует сам.
Наоборот, активно пытаюсь выяснить, действительно ли вакум работает еще и дефрагом на пол-ставки, или это ты фантазируешь.
Ты опиши дефрагментации чего именно ты от него ожидаешь?
Ну да, большинство СУБД будет даватьприемлемую производительность даже при относительно большой фрагментации, так что при правильно построенной таблице без дефрагментации можно обойдись.
опять абстракции «большинство», «приемлемую», «относительно», «правильно построенную», «можно».
Кластерном индексе каждый момент времени переписывается одна страница, соответсвенно разнуливать нужно только ее модификации.
Ты все еще о полном перебилде кластерного индекса?
Опять мимо
А это тогда что?
Если есть одна запись уже для слова, которая в середине страницы
есть 100500 других кейсов когда все будет не так хорошо?
Что еще есть из кейсов кроме редко встречающихся слов?
Ну вот у тебя уже не поехала, 17сек и все такое.
Ну во первых в эту я как раз не заливал бензина, а во вторых у меня есть туева хуча, которые поехали.
А он и освобождает место, просто не отдает его ФС, а использует сам.
При полоном вакуме написано что отдает.
Ты опиши дефрагментации чего именно ты от него ожидаешь?
Для простоты объяснений предположим, что у тебя файловая система выделяет кусок в 100 байт, в котором помещается 100 айдишников по 1 байту. Ты выделил первый кусок, и написал туда 100 айдишиников для 100 петвых слов. Потом во второй кусок 100 айдишников для вторых слов. Потом в 99 первых слов ты добавил еще по одному докайди. В итоге айдишники для этих 99 слов перепишутся куда то в другое место и 99 байт освободятся в первом куске. Во втором куске — то же самое. От дефрагментации я ожидаю, что дефрагментатор сдвинет оставшийся в первом куске байт в начало, а оставшийся байт из второго куска положит сразу за первым.
Ты все еще о полном перебилде кластерного индекса?
О нем родимом.
А это тогда что?
А что именно тебя смущает?
Что еще есть из кейсов кроме редко встречающихся слов?
А редковстречающихся слов недостаточно?
Ну во первых в эту я как раз не заливал бензина, а во вторых у меня есть туева хуча, которые поехали.
Возможно, но медленно и/или на других задачах
При полоном вакуме написано что отдает.
Клево, а при неполном, он отдает, и че сказать хотел?
От дефрагментации я ожидаю, что дефрагментатор сдвинет оставшийся в первом куске байт в начало, а оставшийся байт из второго куска положит сразу за первым.
Такого обычный вакуум видимо не делает, он просто позволяет переиспользовать предыдущие 99 байт когда для этого возникнет необходимость.
О нем родимом.
Ну видимо в постгресе при полном вакууме «каждый момент времени переписывается одна страница» в той же мере как и пре ребилде кластерного индекса. Все еще непонятно почему тебе нравится ребилд кластерного индекса но не нравится полный вакуум.
А что именно тебя смущает?
Меня ничего не смущает. Я просто тебе показал твое предположение, которое ты по твоим словам не делал. Или что ты имел в виду под «опять мимо?»
А редковстречающихся слов недостаточно?
В редковстречающихс словах проблема фрагментации не актуальна, т.к. для них не надо читать много страниц сразу.
и че сказать хотел?
Что стандартный вакум не делает дефрагментации, в отличи от полного.
предыдущие 99 байт когда для этого возникнет необходимость
Хорошо если пустыми будут все 99, а если они через один удалятся?
Все еще непонятно почему тебе нравится ребилд кластерного индекса но не нравится полный вакуум.
Я не говорю, что он мне нравится, я говорю, что это решение проблемы фрагментации, в то время как ты вообще не признаешь наличие проблемы фрагментации в постгресе, считая что тот волшебным образом все разрулит.
Меня ничего не смущает. Я просто тебе показал твое предположение, которое ты по твоим словам не делал. Или что ты имел в виду под «опять мимо?»
По каким это именно словам я не делал какое предположение?
В редковстречающихс словах проблема фрагментации не актуальна, т.к. для них не надо читать много страниц сразу.
Да, в твоем подходе вставка будет тормозить на редковстречаемых словах, а поиск на частовстречаемых словах, поскольку обычно в тексте есть и те и те, твой подход тормозит везде.
Что стандартный вакум не делает дефрагментации, в отличи от полного.
Ок, пусть стандартный вакуум не делает дефрагментацию.
Хорошо если пустыми будут все 99, а если они через один удалятся?
Это риторический вопрос, или ты хочешь опять какими то дальними окольными путями натолкнуть меня на какую то мысль, которая тебе кажется умной? Помоему ответ очевиден.
Я не говорю, что он мне нравится, я говорю, что это решение проблемы фрагментации, в то время как ты вообще не признаешь наличие проблемы фрагментации в постгресе, считая что тот волшебным образом все разрулит.
В моем подходе проблема фрагментации не влияет на производительность, потому что мои массивы записываются целостным куском на диск. Наверное есть некий оверхед по использованию места, наверное есть какие то неиспользуемые дырки на диске, но насколько это проблема, для меня не очевидно, a для тебя?
По каким это именно словам я не делал какое предположение?
Предположение, что моя фраза «если есть одна страница» значит «если есть хотя бы одна запись».
Это риторический вопрос
Нет, я просто пытаюсь выяснить, насколько проблема фрагментации будет серьезной. Допустим ты наделал туеву хучу дырок различного размера и теперь тебе надо положить целый кусок размером, допустим, 50 байт. Как это технически будет происходить? Надо будет пробежать весь диск с начала в поисках дырки подходящего размера?
Наверное есть некий оверхед по использованию места
 У тебя есть какие то гарантии, что этот оверхед не будет в разы больше хранимых данных?

А зачем дырки ? Горизонтальное масштабирование же. Часть серверов «законсервированы», а часть активно обновляются. Запрос пускается сразу на два инстанца и потом результаты мержатся в один.

Бррр.. Звучит как «волны перекатывались через мол и падали вниз стремительным домкратом». Можно поподробнее или хотя бы ссылку технические подробности?

Ну я как понимаю у вас вопрос, что будет если произойдет вставка документа в середину, ну или его обновление.
Так я отвечаю, для своего случая, что делается два сервера. Один «законсервированный», который хранит инфо которая не менялась. Второй сервер «live». Все новые и редактированые документы попадают на «live». И дальше логика, смотрим на сервере «live», если не нашли новой версии, смотрим на законсервированных серверах. Ну и плюс планово консервация данных с серверов «live», допустим еженедельно. Мержатся два индекса в один монолитный, это у меня тоже уже реализовано, много времени не занимает. Скажем чтобы смержить две половинки индекса каждый на 250 ГБ инфы, это займет гдето минут 15 времени.

вставка документа в середину
В середину чего? О каких конкретно серверах речь?
Все новые и редактированые документы попадают на «live»
Если новые документы и так попадают в лайв, зачем тогда законсервированные сервера?
В середину чего? О каких конкретно серверах речь?

Ну вы обсуждаете там какието дырки в индексе. Есть и более красивые архитектурные решения.

Если новые документы и так попадают в лайв, зачем тогда законсервированные сервера?

Законсервированные сервера работают всегда в режиме ReadOnly. Данные там упакованы и максимально дефрагментированы. А live сервера содержат обрывки новой информации, зачастую хранят их в ОЗУ.

Ну вы обсуждаете там какието дырки в индексе.
Мы обсуждаем проблему фрагментации при хранении данных произвольной длинны на диске. Про дырки в индексе речи не было.
Есть и более красивые архитектурные решения.
Эти архитектурные решения имеют какое-то название или это Ваше ноу хау?
Эти архитектурные решения имеют какое-то название или это Ваше ноу хау?

Кеширующие сервера.

Какая СУБД, и что хранится в иднексах?

noSQL, в индексах хранятся факты, о документах и словах в этих документах

Короче я нашел более доходчивый пример. Допустим у вас абстрактная задача, хранить 100 млрд отсортированых обьектов. Их реально дохрена и они хранятся на диске как массив. Также у вас есть еще одна задача, каждую секунду сюда добавляется 10 новых обьектов. Выход примерно такой. Сделать кеширующий сервер, на который в течении дня скидывать новые обьекты. А в конце дня ну или когда там переполнится кеширующий сервер, брать и перезаписывать весь индекс по новой, мержить две последовательност. Новые обьекты сбрасываются с кеширующего сервера на основной.

noSQL, в индексах хранятся факты, о документах и словах
 Я не слишком знаком с noSQL, поэтому пару вопросов — что представляют собой факты о документах?
Допустим у вас абстрактная задача, хранить 100 млрд отсортированых обьектов.
Отсортированы физически? В каком порядке?
Предположение, что моя фраза «если есть одна страница» значит «если есть хотя бы одна запись».
И где тут мои слова?
Нет, я просто пытаюсь выяснить, насколько проблема фрагментации будет серьезной. Допустим ты наделал туеву хучу дырок различного размера и теперь тебе надо положить целый кусок размером, допустим, 50 байт. Как это технически будет происходить? Надо будет пробежать весь диск с начала в поисках дырки подходящего размера?
очевидно постгрес держит какие то структуры, которые позволяют быстро находить незаполненное место.
У тебя есть какие то гарантии, что этот оверхед не будет в разы больше хранимых данных?
Нету, но если это будет критической проблемой, так уж и быть, сделаю полный вакуум. Хотя у меня такого еще не было.
И где тут мои слова?
твои слова я привел выше
Если есть одна запись уже для слова, которая в середине страницы
очевидно постгрес держит какие то структуры, которые позволяют быстро находить незаполненное место
Если тебе это очевидно, как по твоему выглядят подобные структуры и сколько они добавляют своего оверхеда? По моему более очевидно, что постгрес решает эту проблему старым добрым методом — пихает данные в первую попавшуюся дырку, что не влезет — в следующую и т.д.
Хотя у меня такого еще не было.
Ты гонял именно эту задачу именно в этой реализации на больших массивах данных?
твои слова я привел выше
\
Я так и не понял как из этих двух предложений следует что я «свои аргументы приводил исходя из предположения» «страница=запись», и где я говорил что твоя фраза «если есть одна страница» значит «если есть хотя бы одна запись»?

Ты помоему в какую то полную ахенею ударился.

По моему более очевидно, что постгрес решает эту проблему старым добрым методом — пихает данные в первую попавшуюся дырку, что не влезет — в следующую и т.д.
Да, именно для этого думаю он и использует структуры данных, с поправкой до «в первую попавшуюся», что совсем не то же что " Надо будет пробежать весь диск с начала в поисках дырки подходящего размера".
Ты гонял именно эту задачу именно в этой реализации на больших массивах данных?
Террабайтик подойдет?

Смотря какая база. Может там колонка блоб с hd фильмом. 50 строк и привет терабайт :)

Не, это финансовые транзакции, один документ — куча полей с коротким(в основном) текстом. Когда был террабайт, было около миллиарда документов в индексе.

Вот мой пост

слово+айди будет всегда вставлять в конец страницы, если для данного слова есть хотя бы одна страница. Представь, что докайди тоже не возрастают и почуствуй разницу.
на что ты ответил
Это полная ерунда. Если есть одна запись уже для слова, которая в середине страницы, то следующая запись для этого слова приземлится точно в середину страницы а не в конец
При том, что я не имел в виду запись для слова в середине страницы, это всего лишь твое предположения.
Да, именно для этого думаю он и использует структуры данных
Тогда пропадает главная возможность, которой ты так горился — писать и читать данные одним целым куском. Кстати, почему ты так уверен, что постгрес пишет данные именно так?
Террабайтик подойдет?
Нормально так. И какая в итоге получилась фрагментация после того, как ты все загрузил?
При том, что я не имел в виду запись для слова в середине страницы, это всего лишь твое предположения.
Ну да, я тебе написал, что твое предположение что запись будет всегда вставлятся в конец страницы — полная ахинея, и привел пример когда это не соблюдается, и пример совсем не исходил из предположения что запись = страница, как это ты нафантазировал. Теперь я понимаю, что твое «для данного слова есть хотя бы одна страница» означает на самом деле что слово занимает всю страницу, но изначально думаю об этом догадаться было крайне не просто.
Тогда пропадает главная возможность, которой ты так горился — писать и читать данные одним целым куском.
Это еще почему?
Кстати, почему ты так уверен, что постгрес пишет данные именно так?
Так это как?
Нормально так. И какая в итоге получилась фрагментация после того, как ты все загрузил?
Я не парился этой темой.
Это еще почему?
Потому, что в описанном мною случае, если тебе надо вставить 50 байт, а первые 5 дырок размером 10 байт, то данные вполне могут записаться пятью кусками. Или ты думаешь, что посгрес хранит и обновляет данные о дырках каждого размера?
Так это как?
Так это непременно одним неразрывным куском.
Я не парился этой темой.
Просто там выше по теме аргументировал, что твое решение будет занимать меньше места, хотя на самом деле оно может оказаться в разы больше расчетного.
Потому, что в описанном мною случае, если тебе надо вставить 50 байт, а первые 5 дырок размером 10 байт, то данные вполне могут записаться пятью кусками. Или ты думаешь, что посгрес хранит и обновляет данные о дырках каждого размера?
Постгрес записывает строки в таблице сплошным куском, если 10 байт не хватает, то он запишет в другое место где хватает.
Так это непременно одним неразрывным куском.
Потому что я разбирался с этим ворпосом, доки всякие читал. В постгресе rows неделимы, и всегда пишутся одним куском, пока не достигнут какого то threshold, после которого сплитятся на части. Все эти параметры конфигурируются, и я их выставил большими.
В постгресе rows неделимы, и всегда пишутся одним куском
 А в постгресе массив переменной длинны является частью строки? Потому как обычно в СУБД проблема размещения заранее поля заранее неизвестного объема (текст например) решается путем добавления в строку указателя, где именно этот текст хранится, но строка при этом фиксированной длинны.
А в постгресе массив переменной длинны
В постгресе есть абстрактный item, для обычной строки item = row, для row с колонкой неизвестной величины (TOAST) он может быть одним или несколькими айтемами если достигнет threshold. Как внутренне это представлено, где там какие указатели, я не в курсе.

Кто с Черкас, местный форум forumua.org на
167 тысяч страниц ушел в индекс. Ценность его в том, что содержатся ассоциации на все события последних месяцев в Украине.
ЗЫ: На очереди форекс форум.

Google VS Booben, Fight !!!

Написал небольшой обзор и сравнение :)

blog.pikosec.com/?p=72

Только час назад избавился от акций гугла, как знал...

Кстати, а ты не пробовал связаться с владельцами сайта v-search.org? Они пытаются потеснить яндекс и гугл с рынка, уже написали свои карты, аналитику, рекламу, аналог дропбокса, думаю поиск у них тоже стратегическое направление. И инвестиции вроде у них есть.

У них же просто Апи к гуглу ?
Гугл если почуствует дискомфорт просто забанит их айпишники )

Да, поэтому у них есть мотивация например купить твой движек.

Ну не знаю, помните как у Воланда из Мастер Маргариты, Булгакова
"Никогда ни у кого ничего не просите, прийдет время сами все предложат и дадут"©

Он бы может и рад предложить, но не знает о твоем поисковике.

Забавно, ввёл слово «Могущество» — вывел первой тему «Китай ого».
booben.com/...щество&s=sql.ru

Иногда мне кажется что алгоритм «соображает» больше чем расчитано )

Кто кодил Доу ? Столкнулся с эпик феилом, разметка страниц меняется в зависимости от давности топика. Неужели страницы закешированы в СУБД в денормализированом виде ?
Хотел написать небольшой парсер по фильтрации банеров и прочьего муссора.
На других форумах такой проблемы ( пока что ) не обнаружено.

Скоро у вебмастеров кроме SEO появится BEO (Booben Engine Optimization).

Ну да, не плохо было бы провести BEO =)
Ато в новый индекс рискует попасть всего 20% топиков ( с новой разметкой ) =)

А если серьезно, может быть просто выгрузить в CSV все топики и подарить мне на доброе дело ? Если разметка гуляет парсер будет весь в костылях =(

Делаем поиск по слову «разметка» booben.com/...&s=habrahabr.ru

Четвертая статья в топе «Вредная верстка», пункт про SEO

і правильно
а то геть сором втратили, написали щось таке, що бідний бубенчик не може розпарсити сторінки для свого нац проекту

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

Тут часто просят рассказать про алгоритм.
Ничего сложного в нем нет, тема не нова, чемто похож на пресловутый гугловский Page Rank. Но если Page Rank ориентирован на ранжирование сайтов между собой, то мой алгоритм ориентирован на ранжирование страниц внутри одного сайта. Суть его в следующем. Каждая страница пытается утверждть какието факты. Таких фактов на каждой странице может находится от сотен до тысяч. Чем больше один и тотже факт утверждают разные страницы, тем истенней считается этот факт. Наиболее авторитетными считаются те страницы, которые утверждают как можно больше истинных фактов.

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

страница пытается утверждать какие-то факты
Какова примерная структура факта и как он выделяется из текста страницы?
утверждают как можно больше истинных фактов.
Как оценивается степень истинности?

Структура факта простая. Например «путин х*ло».
И чем чаще разные страницы это утверждают тем истенней считается этот факт.
Скорей всего так будет на украинских форумах. На русских будут обычные связи типо «президент правительство корупция медведев» ...

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

Общество потребитель поиска. Общество формирует критерии истинности, делая те или иные факты массовыми. Сеть лишь отражение социума с его предпочтениями и заблуждениями. Поэтому на русском форуме слово сало или борщ ведет гарантировано на хохлосрач, потому что в другом контексте просто там не упоминается. А у нас слово х*ло ведет на страницы с путиным. Так что все по честному :)

А гугл или яндекс пытается всех подомнять под одну гребенку, распространив критерии истинности одни на всех.

То есть правда и ложь приобрели национальный окрас и меняются местами в зависимости от сектора Сети? А при пересечении границ сейчас вместе со штампом в паспорте надо и в голове менять какие-то настройки.

Это демократия © Вы же не хотите по слову «трактор» на доу отискать виды сельскохозяйствено техники ? ) Ведь это слово тут употребляется в другом контексте. Общество поменяло его смысл, конкретно на этом ресурсе. На другом ресурсе оно может иметь другой смысл.

А сейчас проиндексируй эту страницу — и узнай кто ты.
booben.com/...booben&s=dou.ua
Считаю, на этом тема закрыта.

Вот и я о том же — кидая говно на вентилятор, не забывай о рекурсии.

Важко дати відгук про систему оскільки не підтримуються запити на декілька слів, не бачу застосування в реальному житті (поки що).
Демонстрації зводяться до пошуку абстрактних слів. Насправді, пошуковик дуууже складна система (я думаю ви в курсі :) ) і одним алгоритмом тут не обійдешся.
Н-д, запит «хміль» — що я саме шукаю? Яку користь несуть в собі асоціації «хмиль хмиля 1077 живя комуналь квартири 200к бедности tax садик однушка скатывае доходом гринкарт садики 50к середньо 20к йорку платити почина зажравши гопников borisenk середн »?

Покажіть use cases де перевага відчувається?

Поиск имеет более качественную выдачу, основанную на ассоциативных связях в тексте.

Є метрики (NDCG н-д), порахуйте й покажіть.

Але удачі. Цікаво було б почитати про алгоритм.

Вам надо что-то придумать с баннерами, серьезно

Переиндексированы все ресурсы с фильтрацией муссора !
Качество поиска заметно улучшилось.

млдц, тк држть!

Это всё равно что показать кучу навоза — и утверждать что это будет картошка. Может она и будет, но либо доделай показывай картошку, либо называй дерьмо дерьмом и объясняй как из этого будет картошка.

Ты ни слова не говоришь о самом алгоритме, кроме того что он «уникальный», «новый», «более качественный». Но в результате... шлюхи есть, а блэк-джек где? А лунапарк — где???

Для примера: ты ищешь «трактор». Твой запрос должен вернуть слова «иммиграция», «релокейшен». У тебя — банальщина вроде первых версий Яндекса. Итого: ты промахнулся по синонимам, не связав тематику со словарным набором. Ты полез индексировать комментарии, проигнорив более чем 100-кратный вес топика по сравнению с ними — в результате вырвал найденное из контекста.

Резюме: может в программировании ты и силён, но чтобы делать поисковый движок — тебе нужно 99% лингвистики и 1% программирования. Нужно разбираться в человеческих языках. И уверяю, в разных группах языков конструкции будут отличаться. В частности, для русского важную роль играют падежи, знаки припинания и выделения, заголовки текста, часть речи к которой относится слово.

ЗЫ. ДОУ проиндексирован отвратительно. Ты не учёл, что темы выводятся списком постранично. Нужно было пройти итератором до упора, а не на глубину ссылок. Список ведь явно длиннее 10 страниц!

Я вроде как писал, что на Доу всего 5,5 тыс обвешеных банерами страниц, что мало для качественного ассоциативного поиска. Для базы знаний нужно от 100К страниц. Чтобы не быть голословными, приведите запрос, который не выдал вам релевантный результат. Попробую помочь.

Все выкачанные страницы скуль ру весят 56 ГБ хтмл текста (~1.5 млн страниц).
Доу — 1 гб

Вероятно твоему роботу просто все не отдали, посчитав DOS-ботом. К тому же я нашёл устаревшие страницы. Ты вообще когда индексировал?

Далее — ты не отделил вспомогательных данных от текстовых, и проиндексировал лайки.

В общем, мой совет — сначала задайся целью ЗАЧЕМ ты строишь индекс, для какой задачи. А уже затем индексируй. Потому что это ЗАЧЕМ и будет определять логику языковой связи. Люди именно так и воспринимают язык — через фильтр шаблонов и асоциаций. Но при этом у них в голове УЖЕ заложен лингвистический фильтр — синонимы, частотные ассоциации, тематические ассоциации.

Другими словами, всё что ты сейчас добился — это учишь робота языку. Но никакой практической пользы это не даст, ибо всё что ты нашёл — секрет Полишинеля. Ты выдаёшь в результате часто употребимые СЛОВА языка. Но смысловую нагрузку несут лишь редкие. И чем слово реже — тем его ассоциативный вес больше.

К примеру, попробуй искать по слову «хуй». У тебя нарисуется явный вектор смысла. А реально это слово не должно давать ассоциаций вообще. Ноль. Это — местоимение!

Кстати, заметил любопытнейшую вещь. В тех ТЕКСТОВЫХ результатах что ты находишь — слова-ассоциации ПРАВИЛЬНЫЕ. То бишь, как раз там самое интересное и лежит. Например, по слову «доллар» сразу же находится Гаврилюк. Именно этот человек здесь вангует доллар и вообще любит конспирологию. И заметь, это слово ЧАСТО совместимо с долларом ЗДЕСЬ, но является редким В СЛОВАРЕ русского, и тем более в общей базе словосочетаний. Следовательно — это и есть знание, которое ты нашёл.

К примеру, попробуй искать по слову «хуй». У тебя нарисуется явный вектор смысла. А реально это слово не должно давать ассоциаций вообще. Ноль. Это — местоимение!

А почему это слово не должно давать ассоциаций ? Если вы о нем подумаете, то определенные специфические асоциации у вас в голове всетаки возникнут. Почему же движок должен скипнуть сей популярный термин ?

Ну а в целом, Вы немного не в ту степь побежали. И я бы даже сказал, что концентрация на «местоимениях», «запятых» и «точках» это гарантированый эпик феил проекта.

Я просто скажу, что Гугл не даром пытается проиндексировать так много информации. На больших обьемах данных и мартышку можно научить читать. Гугл это уже понял. На огромных обьемах информации работают другие законы. Такаяже разница как между микромиром физики и макромиром. Вот Вы пытаетесь прикрутить законы микромира (квантового мира) на макро мир огромных обьемов информации. А это ошибка. Там другие законы работают.

Тогда поздравляю с фейлом проекта. Ибо всё что происходит в IT — это микромир. Прорывы осуществляются в понимании единичного объекта и его связи. С последующим масштабированием.

PS. Мартышкам всё время пока развивается человечество — доступны данные о языке. И чё, много читать научились?

Алексей, вижу что Вы любите философский подход. Попробую подойти тоже с философской точки зрения. Вот представьте что у вас есть десять соток земли. Всю жизнь вы прожили на грядках выращивая картошку. У вас отлично облагороженый компактный участок с хозяйственными постройками. Единственное что вас волнует, это кирпичный сарай соседа улучшеной планировки, который вам пока что не по карману. А потом както вдруг Вы попали в Межигорьре... И переосмыслили смысл жизни. Понимаете, вы мне про микропоказатели «про улучшения урожая картошки на 3.5%, если качественно улучшить процесс прополки грядок картошки», а я вам «нужно тырить газ !». Ну масштабы совершенно другие.

Если пример с Межигорьем совсем уж философский то у меня есть пример ближе к делу. Вот возьмем пресловутые баннеры хабра, которые попали в индексанцию. Это катастрофа. Но это катастрофа локального масштаба, когда у вас проиндексировано 10К страниц. Когда у вас проиндексировано 1 миллиард страниц, роль проиндексированый банеров на хабре стремится к нулю. Влияние дискретных флуктуаций ошибочной информации в общем океане информации стремится к нулю. И вы можете просто забить болт на банеры, ничего не делать и при этом получить хороший результат. Другие подходы. Другие масштабы. Другие алгоритмы. Но это понимание конечно приходит не сразу.Нужно выйти за рамки микромира.

ЗЫ: Кстате сьездите в Межигорье если не были. Там классно )

Ну, с таким подходом вам прямая дорога в Партию Регионов Партию Развития. Глядишь, встретимся на майдане. По разные стороны баррикад.

А может сразу, ну его нафиг тот движок — рванёшь на Донбасс, вступишь в ополчение — знаешь какие там деньжыщщи платят! Может даже президентом республики станешь.

У меня цели немножко другие. Не хочется чтобы страна ассоциировалась с майданом или «ополчением». Впрочем я вижу что предметной дискусии не получится, за сим откланиваюсь.

приведите запрос, который не выдал вам релевантный результат.
Хм, а такой?
booben.com/...&s=habrahabr.ru

Видите этот пик, это баннер попал в индексацию.
booben.com/...&s=habrahabr.ru

Если отсеять баннер то все будет Ок.
booben.com/...ефония&s=sql.ru

Кстате о Тракторе, в топе только темы которые связаны с эммиграцией. На счет «я расчитывал увидеть в списке ассоциаций чтото другое», нужно иметь на руках статистику по сайту и тогда уже рассуждать. Например слово «Релокация» не найдена в основной теме про трактор «Канада, как надо, или информация будущим трактористам» на тыс. страниц. Так что все нормально работает.

баннер детектед. Не мучаем себя раскладками и пишем жаргонное имя )

www.booben.com/...&s=habrahabr.ru

Google вам всё равно не догнать, но вы можете сделать конкурента MegaIndex.ru. Это не поисковик, но отчасти похоже.

Честно говоря, совсем не то, что ожидалось
booben.com/...&s=habrahabr.ru

НО, задумка интересная и похвальная. Желаю успехов, надеюсь что-то получится толковое

Это вы похоже попали на баннер на хабре :(
К сожалению написать толковый а главное быстрый паук, который будет отсекать муссор еще один большой кусок работы.

Лучше ищет, например, айфон или джобс
booben.com/...&s=habrahabr.ru
booben.com/...&s=habrahabr.ru

Жаргонные названия не используют на официальных баннерах.
Ну или поискать Андроид на сайтах, которые меньше увешены баннерами.

booben.com/...ндроид&s=sql.ru
booben.com/...ид&s=gamedev.ru

Вот кстате видно по графигу, как баннер про андроид подмешивался в индексацию.

booben.com/...&s=habrahabr.ru

“Абсолютно новый алгоритм” з “нескучным интерфейсом”, якщо я все правильно зрозумів.

если вы проект не забросите, то поделитесь снова, тем что уже будет где-то через полгода, интересно посмотреть будет, думаю мелкие баги вы порешаете, может и станет проект достойной альтернативой тому же сфинксу

пока забрасывать не планирую =)
последнюю неделю аудитория поисковика стабильно растет на +20% в сутки, при нулевых вложениях в рекламу и абсолютно никудышном дизайне

А программист/разработчик искать не пробовали? :)

Слово программист/разработчик встречается на каждой второй странице здесь. По этой причине желательно избегать официальных названий и попробовать чтото жаргонное.
Например: booben.com/...елопер&s=dou.ua

В топе статья:
В общем в одной из наверное самых читаемых винницких газет “РИА” вышла статья про программистов под заголовком “Хто має клепку — той стане програмістом і без вищої освіти”

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

Коментар порушує правила спільноти і видалений модераторами.

релевантненько так, возможные ассоциации хардкодом в базе идут?

нет, ассоциации высчитываются полностью автоматически. Причем этот процесс никак не привязан к языку, не привязан даже к разметке страницы (индексируется все с банерным муссором). По сути, мы можем скормить движку, к примеру, пуартериканский форум и получить тотже эффект. Чем больше обьем текста, тем лучше эффект. Двиг самообучится, построит ассоциативные сети и будет искать по правилам пуартериканской культуры.

а если скормить гугловские петабайты информации, то вполне бубен может попросить ваш мотоцикл и куртку :D (ну типа шутка, ато налетят щас всякие джависты)

Кстате, по возможности уже вошло в привычку пользоваться только своим поисковиком
booben.com/...=всерч&s=dou.ua

почитаю сказки на ночь от всёрча )

Тут ще одне: Гугл, Яндекс та інші не просто так по-різному ранжують тайтл сторінок, дескріпшн, якийсь об’єм тексту на початку, та все що залишається. Проіндексуйте Вікіпедію і самі все побачите.

Проблема в том что крупные поисковики дальше тайтла страниц уже даже ленятся ходить.
Сухой машинный поиск. Хотел, например, про «кота», получил 100500 страниц где в заголовке слово «кот».

Вот к примеру что выдает Гугл по слову Кот на хабре.
Аналитика. Кот. Пятница — Хабрахабр
Автоматизация смыва унитаза на Arduino + Z-Wave

А вот у меня:
Гуманная и эффективная мышеловка / Хабрахабр
Лучший друг айтишника / Хабрахабр

Чувствуете разницу ?

Різницю-то я відчуваю, але є одне “але”. На прикладі “кота”, якщо вірити виділенням, багато сторінок потрапило до видачі не через те, що вони про мишей (та й слова “миш” я в асоціаціях не побачив), чи хоча б про тварин, а через те, що в словах:
которые
некоторые
було ідентифіковано саме “кота”.

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

можливо, але краулер мав би це якось резолвити. Бо в світі повно глюканутих сайтів, та сайтів що створюються виключно для потрапляння у пошук.

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

Запрос по слову Арни.
yandex.ru/...te:sql.ru&lr=65

Первая тема попала в топ только из-за заголовка.
Вторая тема в топе вообще какойто левак
тип DATE Сложение и вычитание / Firebird, InterBase / Sql.ru

Теперь сравните что выдает Бубен в топе
booben.com/...q=арни&s=sql.ru

А новейший антивирус и архиватор чтобы сжимать фильмы в миллионы раз случайно не ваши «изобретения»? Не узнаю вас в гриме, это вы: lurkmore.to/...лексей_Бабушкин ?

Для писсимистов, пожалуй поднаброшу :)
http://searchengines.guru/attachment.php?attachmentid=136976&stc=1&d=1408523563
Это не очередной апи гугла или яндекса. Это не сфинкс, люсена, солар или чтото еще. Применяются специальные ранжирующие алгоритмы, которые строят чтото вроде нейросети ассоциаций и по ним отискивают наиболее релевантные документы.

А з чого ви власне радієте та чим пишаєтеся? На sql.ru дійсно дофіга тем зі словом “сало” у самісінькому тайтлі, а ви пропонуєте відвідувачам взяти участь у хохлосрачі? А що робити тим, кому дійсно потрібне сало, ну, скажемо, синичок годувати?

Мені алгоритм роботи нагадав один анекдот про жіночу логіку:

“Еду в автобусе. Надо передать за проезд. Рядом стоит девушка, как к ней обратиться на ты или на вы? Рассуждаю логически. Этот автобус-экспресс. Если девушка не сошла на предыдущей остановке значит она едет в мой район. Едет с бутылкой вина значит к мужчине. Вино дорогое значит к красивому мужчине. В нашем дворе двое красивых мужчин, мои муж и мой любовник. К моему любовнику она ехать не может, так как к нему еду я. Значит она едет к моему мужу. У моего мужа две любовницы: Катя и Оля. Катя сейчас в командировке.
— Оля, передай за проезд пожалуйста. (девушка ошеломленно)
— Откуда вы меня знаете?”

Але на відміну від анекдотичної ситуації для пошукової системи така логіка може бути прийнятною або ж just for lulz, або ж з точки зору людей, що недосконало володіють мовою.

Я с вами от части согласен. Есть энциклопедическая модель поиска. Есть ассоциативная. Энциклопедическая хороша только от части, особенно когда речь идет о социальных ресурсах. Потому что на социальных ресурсках культивируется уникальная субкультура и ассоциативные сети позволяют находить более интересные результаты в духе базы знаний самого форума.

Кто-нибудь может объяснить почему топикстартера начали обливать говном? Вроде бы не очередной v-search пришел презентовать.

А потом дядя Азиров стучит по столу и допытывается почему до сих пор не написали украинский гугл

Дяді азірову зараз не до того, йому б від європейських геїв відбитися, що тільки і мріють позбавити його цнотливості.

Украинский гугл звучит как китайский iPhone или как «ксерокс фирмы panasonic», т.е. есть видимый лидер которого не побить, я лично не вижу смысла в такой гонке за лидером, мы не Pepsi, второй кока-колой не будем. Азiров возможно хотел под это дополнительно попилить бюджетные суммы, хорошо что ему не дали.

Теперь по теме: явно сырое нечно с совершенно нерелевантным поиском, досадными недоработками, огрехами в морфологии и даже базовом стеминге слов, дизайн сворованый у гугла (возможно не только дизайн). В ответ на в общем-то объективные замечания по дизайну, юзабилити, функционалу поциент автор показал всем свой уровень пустившись обсуждать личности и профессиональный уровень комментаторов, чем показал свою в общем-то неадекватность, далее развитие дискуссии пошло как обычно.

www.booben.com/...&s=habrahabr.ru
чем он нерелевантный?

чем показал свою в общем-то неадекватность, далее развитие дискуссии пошло как обычно.
Габриэль, свою неадекватность, как обычно, показал ты, когда начал придираться к цветам логотипа и неправильной кодировке, после чего передал эстафету со своим shit bucket challenge

booben.com/...&s=habrahabr.ru
booben.com/...&s=habrahabr.ru (причем здесь Чак Норрис?)
booben.com/...&s=habrahabr.ru (mysql, media, create, ruby) — супер.
Дальше продолжать не вижу смысла, вы бы прежде чем троллить попробовали поискать что-то дельное, а то вброс мимо кассы.

Онотоле — він же ж як Чак Норріс, але цнотливіший ))

1. Онотоле связало с Вассерманом. Что не так ? Чак Норрис предложил как возможность перейти на похожую тему. Что онотоле что чак упоминаются как полувымышленные персонажи.
2. Уже писал, пишите «джава», «руби», «дотнет», «медиа» и тд.

Вот кстате интересный пример еще.
По запросу «Чак», сравнение Гугла и Бубна

Гугл предложил
www.google.com.ua/...abrahabr.ru чак

== Топ Гугла ==
Джеф Дин
Чак Норрис и Google Glass
Левак — Топики / Избранное / Хабрацентр им. temujin / Хабрахабр

== Топ Бубна ==
booben.com/...&s=habrahabr.ru

Чак Норрис одобрил World of Warcraft / Хабрахабр
Лучшие «программистские» шутки о Чаке Норрисе / Хабрахабр
10 марта 1940 года родился Карлос Рэй Норрис / Хабрахабр

Какая выдача лучше — Вам решать. Как минимум они друг друга дополняют.

Украинский гугл звучит как китайский iPhone
т.е. есть видимый лидер которого не побить,
досить сумнівно, бо
1. локальні орієнтовані на місцевий ринок компанії завжди були і будуть
2. вже є українскький гуугл (meta.ua) i він не погано себе почуває.

мета почувае себе не дуже...
а як пошук то взагалі мертва (вже теж стоїть гугл серч)..

майже всі укр. пошуковики закриті = що не критично ІМХО

автору для успіху, ІМХО пено рухатись в сторону sphinxsearch.com
тобто свого рішеня для стороніх проектів під ключ або на підтримці...

бажано не під СНГ )

пришел презентовать.
Пишу с нуля поисковый движок на Си...
...поиск имеет более качественную выдачу, основанную на ассоциативных связях в тексте.
...всё там нормально работает. 500Гб текста проиндексировано.
...ограничение на одно слово временно из-за слабого сервера.
...пересчет нейросети графа очень тяжелое дело
...nosql
Презентовал, да.

А хіба МЕТА не є Український Гуглом? Я завжди так думав, чи я помилявся?

Украинский гугл, это шукалка, а мета давно москалям продалась

Шукалка это морда Яндекса, правда вся в вышиванках.

Печаль, еще была livarava, но похоже она тоже все.

У тебя кстате на хабре нету аккаунта для приглашения ? Хочу там статью написать

Кидай в песочницу, постараемся намутить =)

Спасибо =) К пятнице постараюсь подготовить статью.

Мета уже давно к каталогу скатилась.

Можете озвучить детали реализации? В частности интересует как выполняется индексирование сайта.

За основу можно взять этот неплохой цикл статей. Он дает понимание о масштабе проекта. habrahabr.ru/post/123671
Плюс, определенные детали я выкладываю в своем блоге blog.pikosec.com/?cat=3

Могли бы вы проиндексировать lambda-the-ultimate.org пожалуйста?

там всего 5 тыс тем. Маловато. Но в качестве пробного шара можно попробовать. Я хотел начать покрывать англоязычные форумы тоже.

там всего около 3 тыс тем. Оооочень мало.
Но даже так, вывел старичков программирования — кобол, алгол и др.

За курсовую вам пять однозначно, если код не подкачал.

код подкачал, врядли 23х летняя посредственность из аутсорца с ЧСВ выше 100500 в нем разберется (извините за прямоту).

Вы правы, куда уж нам, а кодировку можно вручную угадывать в браузере, а остальное что не нашло подыскивать в Яндексе. Замечательный продукт — обязательно выходите на IPO.

В этом разница между 23м и не 23м сеньором. 23х летний сеньор уверен что кодировки это сущий пустяк. Накодим за 5 минут.

Вы 23 летний senior? Ну как senior вы должны понимать, что открывать в бету или презентацию откровенно сырой продукт — это epic fail. То что у вас там под капотом — никого не волнует, если нет базовых нормальных фич по типу популярных движков, то вашу поделку никто не будет юзать, особенно если дизайн — какое-то воровство с гугла.

всё там нормально работает. 500Гб текста проиндексировано. Еще запас прочности гдето на 100ТБ точно есть, дальше горизонтальное масштабирование. Сам сайт это отдельный проект, которому меньше недели. Он и лажает с кодировками.

Но как говорил один известный человек, когда умный показывает на небо, идиот смотрит на палец ( в вашей интерпретации на кодировку ). За сим разговор прекращаю. Говорить неочем.

Умный человек смотрит сначала на то, что было уже сделано, но это явно не про вас. Посмотрите на уже готовые бесплатные и производительные движки, их скорость индексации и не позорьтесь: habrahabr.ru/post/30594
Объемы не имеют значения, важна скорость индексирования и поиска + фичи.

Xapian — гівно, Sphinx — няшка! Чого там ще дивитися? )

если экосистема на Java, то рекомендую Solr — это уже готовый, тюнингованый на базовом уровне, достаточно mature поисковый движок скоро 5-я версия, конфиги, настройки, деплой — очень user-friendly.
Elastic search — более новый и тоже вроде неплохой.

Скорость индексирования у меня 100-150 мб/сек на одно ядро. Сжатие 99,5% от первоначального обьема хтмл текста. Короче говоря, молодой человек, давайте я не буду лучше вас тролить, просто какбэ намекну. Что не стоит с напыщеностью киевского сеньора заходить в незнакомую тему, если вы по крайней мере последние пять лет ее не курите с самых низов. Ок ?

Вы вбросили свое г*внецо, а в ответ на заслуженные вопросы и замечания пускаетесь в какие-то персональные срачи, если вы такой умный, почему вы себя ведете как 19-летний студент, собравший на коленке нечто?

бросили говнецо вы, про курсач. И я правильно заподозрил что не от большого ума.

Ну если это не курсач, то тогда что? коммерческий движок — ни в коем случае, open-source-ный, но ведь в спагетти коде по вашим же словам никто не разберется, на диплом нет научной новизны, только курсач.

сливаетесь? есть еще аргументы в гениальности поделки?

сливаетесь? есть еще аргументы в гениальности поделки?

Габрик, ну что ты вечно лезешь и позоришься, когда умные дяди играют мозгами, аки качки мускулами?

Алгоритм, как минимум, заслуживает интереса, даже без реализации. Тема совсем не моя, но хотелось бы видеть статьи хотя бы базовых идей, из которых разрабатывался алгоритм (можно даже с линками на тот же IEEE). Чисто из интереса для себя.

Аффтар, шлюха у вас почемуто проассациировалась со слюнками на доу. Ассоциации глобальные? Откеда он нарыл это?

Ну судя по неревантным результатам: dou.ua/...c/10889/#529163
100-150 мб/сек это даже мало, вы же со скоростью не менее 2000 символов/минута программируете?

А вы прямо себя возомнили уже богатеньким инвестором, раскинувшемся в кресле и приготовившимся отсевать очередного стартапера? От пафоса не треснете?

Сорри, но где вы здесь нашли пафос? Обозвать неуклюжую поделку ее настоящим именем, а автора склочным типом это пафос? Или вы думали что IT-шники приходят в восторг от любой web-странице верстки как 98-го года?

Или вы думали что IT-шники приходят в восторг от любой web-странице верстки как 98-го года?

Ну, ИТшники приходят в восторг от алгоритмов и того, что стоит за их работой. Формошлепы позорные в свою очередь, начинают цепляцца к верстке и прочей галиматье, которая в данном случае вообще не вызывает интереса.

вы наверное не встречались с настоящими 23 летними синьорами

Я так не думаю, он часто наблюдает этот недосягаемый идеал по ту сторону зеркала :-)

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

Кстате подискиваю еще годные ресурсы для индексирования.
Желательно от 100К до 1М постов.

reddit.com но туда можно на год забуриться)

ну гдето давненько я читал что поисковые движки — это все еще круто и много миллионов, но для этого движок должен быть заточен под что то. Например гогл вверху дает выбрать «заточку » - картинки, товары, видео или еще что то. Понятно что гогл покрыл 80-90% нужд, но есть еще 10 процентов в которых можна хорошо жить. На них лучше и сосредоточится.

На данный момент поисковик ориентирован на поиск в социальных ресурсах. Большинство крупных поисковиков сильно не углубляются в субкультуру форумов и выводят в топ темы которые просто имеют в заголовке искомое слово.

ТС, у вас по запиту «шлюхи» першим пунктом видачі йде «Tell me about Ukraine | DOU». А чи ви часом не ватнік? ))

Нет, не ватник.
Главное что Крым алгоритм полностью ассоциирует с Украиной. Проверено на многих ресурсах :)

Один вопрос — на-фи-га?

по запросу «украина» на хабре выдается фигня какая-то
вывод: не движок, а фигня какая-то
Представляет собой ценность только в качестве дипломной работы в КПИ
тчк

Скорей всего Вы попали на банер или подпись пользователя.
Пока что банеры при индексировании я не фильтрую. Потому и результат размыт.

На примере запроса про доллар ясно что стемминг ты еще для себя не открыл.

Стемминг есть, но кроме стемминга есть еще синонимы. Слова с опечатками, в том числе умышленными. Эти вещи пересчитываются зачастую автоматически. И без привязки к языку.

Что то не наблюдаю: доллар доллара доллару долларах

На Доу всего 5,5 тыс страниц, что мало для набора хорошей базы знаний. Попробуйте взять чтото покрупнее для поиска. booben.com/...доллар&s=sql.ru

Что ты чешешь, заюзай портеровский стеммер, он тебе качественно отсечет окончания и будет только «доллар», и «зеркалка» вместо кучи словоформ.

стеммер в чистом виде тебе не поможет
в одной тоолько либрусек базе 13 млн слов в словаре на нескольких языках

К томуже тебе стеммер не свяжет слово, например, «бакс» и «доллар». А у меня связывает. Автоматически.

Ассоциативный поиск, зеркалка:

зеркалка зеркалки зеркалку озабочен злой гей машинами алкоголи подъезда туалете дворе быдло быдла внешност семей дорогое сердца богатый кухне натураль тратят массе женские снизить одежды

Ну что, это успех! :-)

К сожалению, пока что Доу самый маленький из проиндексированых сайтов ) Всего около 5,5 тыс страниц. Чтобы качественно набрать базу знаний нужно хотябы 100к страниц. Можно попробовать на других сайтах поискать, например на хабре.
booben.com/...&s=habrahabr.ru
или скуле
booben.com/...ркалка&s=sql.ru

Вообще фишка поиска в том, что он ищет с учетом субкультуры каждого конкрентно ресурса.

с учетом субкультуры каждого конкрентно ресурса.
Чо?
расшифруйте пожалуйста

на каждом ресурсе есть свои «мемы».
Например слово «печеньки», пошло с сайта sql.ru где манагер завлекал печеньками программистов, чтобы написать соцсеть. Так вот на этом ресурсе, по слову печеньки Вы отискиваете железно тему матку. На другом ресурсе, печеньки могут иметь смысл обычный кулинарный.

сыр по 500 грн,
кстати, а сры про 500 грн это из какой темы?

Не хватает vsearch

резюме junior QA, стоит ли уезжать в Москву,
появилось сегодня: senior-ский борщ в стекляной банке

Странно...
вбил в гугл «мопед не мой» — получил оригинальную тему на втором месте
вбил «работать в нашем банке большая честь» форум иксбита на пятом месте, с ссылкой на тему где упоминается что эту тему выпилили
вобщем ганятся за гуглом это гибое дело,

Гугл не находит тему про печеньки

В либрусеке ( там где 450 тыс книг ) можно искать по фразе. Правда без ассоциаций и ранжирования, только первые вхождения.

Както так, booben.com/...юна&s=librus.ec
Правда там есть эпик фейлы с кодировками, не всегда снапшоты подтягивает

Поздравляю, интересное начинание! Но почему цвета букв в названии напоминают Google?

Пока подискиваю дизайнера, будет тотальный редизайн

Ваш поисковик бесполезен поскольку не позволяет найти порнографию.

А чому тоді по запиту «доллар» не видало тієї сторінки, де «за 100 баксов — в три смичка»? )

баксы отличаются от доллара в данной программе.

Підписатись на коментарі