• 0
    Сниппеты в целом с документами до 200 мб должны успешно работать. Ну и для ветки когда-уже-3.0 сделали Solr-style кеш токенов и хранилку документов, штоп умело только заранее проиндексированные документы подсвечивать, зато быстро и без похода в базу. Пишите почту, выдам preview доступ, если интересно.
    Встреча разработчиков про Sphinx, 18 июня (суббота)
  • +1
    Понятно. Есть пример в misc/suggest/ и собираемся когда-нибудь встроить автоматику в само двигло (начиная с определенного момента данных внутри индекса наконец хватает и это стало возможно).
    Devconf 2016: Интервью с разработчиком SphinxSearch
  • +5
    Ну какой-то shodan написал «ну и я тоже буду присутствовать, участвовать и состоять» — возможно, однофамилец!!!
    Встреча разработчиков про Sphinx, 18 июня (суббота)
  • 0
    Мастер это 2.3 версия.

    Ветку 3.0 откроем, как только переделку формата доведем хотя бы до альфы.
    А вот про Sphinx 3.0
  • 0
    Упс, пропустил комментарий в горке почты.

    Нету сроков. Конец в целом видно, конкретную дату не видно :(
    А вот про Sphinx 3.0
  • +1
    Увы, разработка двигается вот так — небыстро.
    А вот про Sphinx 3.0
  • 0
    1. Инструмент сразу был дрянненький вообще-то, и предназначлся скорее для внутренней отладки. Заменой, как всегда, является штатный запуск searchd и запросы либо через mysql либо любой другой удобный клиент.

    2. Неожиданно, mysql -h0 -P9306, да.

    3. Надо смотреть SHOW META и далее SHOW PLAN, подробности в документации есть.
    А вот про Sphinx 3.0
  • 0
    Ох. Речь вообще не про то, на чем что «надо» делать. Когнитивный диссонас вызывают математика и прилагательные!
    Elasticsearch — сортируем выдачу руками
  • 0
    Реализации поиска в БД и их возможности это отдельный интересный разговор. Там сегодня не так все уже плохо, как ни странно. Но это совершенно нерелевантно. Выбор Эластика как первичного хранилища и вот эти вот вытекающие проблемы и решение — никто ведь не оспаривает (для этого в посте принципе недостаточно данных).

    Меня удивляет другое: порядок 10М документов с намеками, что это как бы нечто неподъемное для РСУБД; отклик 1 msec, используемый для прикидок общего времени исполнения (?!!!); вот это все. Математика не сходится!
    Elasticsearch — сортируем выдачу руками
  • 0
    Специально не стал раписывать подробнее слово «типа», ждал подобного комментария, и вот он прям сразу :)

    Я отлично знаю, что latency может вообще никак быть не связана с bandwidth.

    Однако во-первых, автор топика отчего-то использовал для своих расчетов именно эти самые 1 ms.

    И во-вторых, что главнее, 1 ms латентности это тоже немало.
    Elasticsearch — сортируем выдачу руками
  • +1
    Статья небезынтересная, но блин, вызывает мощнейший когнитивный диссонанс.

    С одной стороны «хотите отсортировать выдачу по количеству просмотров документа», с другой «записывать каждый просмотр в Elasticsearch». Эээ, что?! Окей, быстрых обновлений атрибутивки нету, это тоскливо, когда её таки надо обновлять. Но сырые неагрегированные данные-то совать в поиск, которому нужны только подокументные агрегаты — ууух, по-моему, такое не должно возникать даже в формате заведомо нерабочей идеи :)

    С одной стороны «десятки миллионов документов», с другой «большие масштабы» и как бы противопоставление реляционным СУБД. Эээ, что?! Извините, но уж 10M веб-документов отлично поместятся что в MySQL, что Postgres на 1 (одном) умеренно толстом сервере. Собственно, даже 100M при среднем размере 5K/документ можно полностью в 512 GB памяти запихать, и всё ещё на одном сервере. Да, конечно, встроенный поиск у них типично будет дрянной, но это другая история. Причем, полагаю, с простенькими выборкам по отдельным ключевикам должен более-менее справиться и он.

    С одной стороны «очень быстрое хранилище Redis», с другой 1 ms на запрос, то есть типа 1K rps. Эээ, что?! Даже РСУБД, не говоря уже о специализированных KV хранилках типа memcached, давно пробили 100K rps с одного сервера, а в лабораторных условиях 1M rps. Вот, первый результат в гугле, 400K rps и это 5 лет назад: yoshinorimatsunobu.blogspot.ru/2010/10/using-mysql-as-nosql-story-for.html

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

    upd: поправил опечатки.
    Elasticsearch — сортируем выдачу руками
  • +1
    Оно доступно в SVN транке. Пока неотдокументировано примерно никак с одной стороны и практически нету никаких endpoints и опций к ним с другой, но таки уже:

    searchd
    {
        workers = threadpool
        listen = localhost:9380:http
    }
    
    http://localhost:9380/sql/?query=select%20*%20from%20rt
    
    {
        "attrs": ["id","gid","gid2","date_added","title","content"],
        "matches": [
            [1,1,[5],1428361133,"test one 24 mois","this is my test document number one"],
        ...
    }
    
    А вот про Sphinx 3.0
  • +2
    Да, отключаемо (или не включаемо, пока не решил, какой лучше дефолт).
    А вот про Sphinx 3.0
  • 0
    — это что? Где можно почитать?

    Это как пример эзотерической штуки, из-за которой сконвертировать индекс окажется невозможно. Беспозиционный (частично или полностью) индекс. sphinxsearch.com/docs/current.html#conf-hitless-words
    А вот про Sphinx 3.0
  • +2
    Грядет в этом году. Увы, точнее пока не могу оценить.

    До первой альфы из самого крупного и критичного остался шажок про новый формат полнотекстового индекса. Работы уже ведутся, но ETA мне пока еще непонятен.

    Менеджмент индексов на лету (не только через HTTP) тоже планируется, да. Возможно, не в первой же альфе 3.0, но планируется.
    А вот про Sphinx 3.0
  • –1
    Миграцию как раз конфигурации мы должны суметь сделать сделать довольно легкой. Там основная часть про sources/indexes по существу должна переехать в отдельный indexer.conf практически без изменений, а остального очень мало, это все легко переделать вручную, либо автоматом (условный скрипт upgrade.py) сконвертировать разово.

    Меня больше беспокоит миграция больших индексов, тк. конверсия в новый формат а) будет возможна только при соблюдении ряда условий, dict=keywords + docinfo=extern + еще ряд более эзотерических штук (отсутствие hitless итп), б) даже в случаях, где возможна, может оказаться слишком медленной (ну те. может оказаться проще переналить данные заново, чем сконвертировать существующий индекс). Впрочем, так или иначе оно все решаемо.

    Цена прогресса, шо поделать. Много лет держали бинарную совместимость довольно неплохо, пора наконец разок сломать!!!
    А вот про Sphinx 3.0
  • +1
    Утомленные недостатками Скайпа и прочих IRC друзья делают чатик на стероидах и попросили запостить сюда ссылку. Вход хитрожопый, по приглашениям; поэтому можно считать, что пока что проектик в стадии вечного закрытого бета-теста. Ссылка вот: closedcircles.com/?invite=07e60c3f0117acab0bddb64268ab1f4b01f31c70

    Чатик скорее для программерской тусовки, по меньшей мере пока. Интерфейс взорвёт мозг, всё будет страшно и непонятно и вы оттуда с вероятностью 99% сбежите. Но если вдруг (вдруг) получится с ним справиться, то по сравнению с IRC итп Skype там еще добавляется тредовая структура, емайл нотификации и дайджесты, а самое главное, избирательный контроль «кого хочу читать, кого не хочу, кому показывать мои сообщения, а кому нет»

    IT-чаты или Выжимаем из Skype все соки
  • 0
    summon сработал, а вопрос-то в чем? :)

    ну да, и percolate тоже у нас пока нету — вероятно, через некоторое время будет
    ElasticSearch и поиск наоборот. Percolate API
  • +6
    Тут ошибка в оценке на 2 порядка, 1 твит занимает порядка 3-4 кб, тк. там кроме текста бешеная куча метаданных.
    Twitter передал шести университетам всю базу твитов с 2006 года
  • +1
    Задача приемлемая, можно и с этим жить. На то ведь оно и заманушный конкурс, а не Идеальное ТЗ.

    Но вот организация конкурса, скорость и качество фидбэка просто чудовищные.
    Разгоняем JavaScript вместе (Внимание, конкурс!)
  • +1
    А у нее решения, формально говоря, нету.

    Потому что твое видение «as good as you would expect a good libc to implement such functions» не совпадает с видением организаторов.

    Хуже, я подозреваю, если аккуратно обернуть стандартные strcpy/strcat, решение не проканает.

    И пробовать играть в эту телепатию неинтересно совсем, тк. итерация длится 2 месяца (?!!!) и в ответ приходит стандартная отписка.
    Разгоняем JavaScript вместе (Внимание, конкурс!)
  • +2
    И есть ли скидка для опенсорсных проектов!?
    LibRaw, Coverity SCAN, PVS-Studio
  • 0
    Для меня лично смысл в том, что упакованный словарь форм дает приятный такой баланс между размером данных и скоростью работы.

    Плюс автомат с суффиксами ловко угадывает леммы для неизвестных слов, с хешами тоже можно, но реализация прикидочно помуторнее.
    Способы представления словарей для автоматической обработки текстов
  • 0
    Если бы все было понятно по слайдам, я был бы не нужен!!!
    UNIGINE Open Air 2013. Фотоотчет
  • 0
    Я даже специально написал!
    MySQL клиент формата A4
  • +1
    Бесплатный VS Express, cl /EHsc nanomysql.cpp и должно работать.
    MySQL клиент формата A4
  • 0
    Самое обидное, что я ночью хотел именно и сделать, но с утра забыл :) Готово!
    MySQL клиент формата A4
  • +1
    Точно, спасибо. Добавил! Все не мог вспомнить, как он называется :)
    MySQL клиент формата A4
  • –1
    > с потолка взять утверждение

    «нижних outliers нету (я типа смотрел свои данные)»

    комментарий не читай @ собеседника сразу обсирай
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
  • +1
    Уже жалею, что снова ввязался в обсуждение. Мне кажется, ты споришь сам с собой, подразумевая какой-то свой прошлый опыт (неизвестный более никому), но зато чуть менее, чем полностью игнорируя то, что я тебе пытаюсь рассказывать про этот вполне конкретный случай. После мощного передергивания про «надо изгаляться над данными и выбрать другую метрику» (а этот бред придумал ты, но зачем-то немедленно приписал его мне) продолжать общение вообще, честно говоря, сразу неохота. Так что повторюсь последний раз, чисто для протокола, и хватит.

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

    Но мы говорим про конкретный и нередкий частный случай!

    Нет, и в этом конкретном и в куче подобных частных случаев можно для ежеминутных итераций над фиксированными данными взять таки минимум. Это потому, что распределение скошено, нижних outliers нету (я типа смотрел свои данные), и минимум практически равен медиане. Алле, распределение известно, условия идеализированы (длинное линейное чтение из памяти), время исполнения тут вообще должно быть константой, те. наблюдаемое время t = T + random_noise, где нас интересует фактическое время T. Очевидно, что min(t) = T + min(random_noise) >= T, ситуация «min(t) маленький, но фактическое T большое» невозможна. Подчеркиваю: в данном конкретном классе случаев.

    Есть красивые примеры, что в других классах бенчмарков все бывает сильно не так? Есть убедительные доказательства, что даже в данном классе бенчмарков min(random_noise) бывает сравним по порядку величины с T? Вперед, пиши статью, будет очень интересно почитать.
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
  • 0
    Знание затем, чтобы оперативно сравнивать две версии функции на микробенчмарке, в ходе работы над ними.

    Еще раз: случай абсолютно одинаковый, но время одного исполнения сильно дрожит. По понятным вполне причинам, но с этим нельзя работать. Один (один) долбаный пик иногда сильно сбивает среднее, а он вдобавок не один. Представь ситуацию: в 70% повторов выходит 120+-1 мс, именно это значение (120 мс) и интересует. По существу, медианное. Еще в 30% повторов выходит что угодно от 130 до 150 мс, потому что наведенное (!) разными внешними (!) причинами дрожание. Внезапно, среднее колбасит от 123 до 129 мс, и внезапно, все отдельные изменения в ходе работы, которые реально убирают по 1 мс, бенчмаркать невозможно. А с минимумом возможно, и при этом итерация НЕ должна длиться 1000 повторов.

    Вот можно, кстати, попробовать медиану считать. Этим разом я не попробовал. Но минимум считать еще проще, результат отличается незначительно, и главное: выходит крайне стабильным и эксперименты БЫСТРЫЕ, те. с ним можно ежеминутно работать. А для окончательного мега-бенчмарка, разумеется, нужно и кучу прогонов, и дисперсию, и вообще распределение лучше бы глянуть. Вот и все.
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
  • 0
    Дисперсия там и так маленькая (теоретически вообще 0, все полностью детерминировано же). Так что фокус про «нагрев» и минимум не дисперсию прячет, а решает вообще другую проблему: нестабильные результаты от запуска к запуску на коротких бенчмарках. Результаты хочется стабильные, а не плюс-минус 20%, иначе как сравнивать. Но и получать их хочется за 10 прогонов, а не 1000, иначе каждый запуск больно долго ждать. Получилось вот так.
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
  • –9
    > Развитие ветки обсуждения спровоцировало всё же то, что

    «обсуждать» тут было сразу нечего после 2го моего комментария, а теперь уже абсолютно нечего

    > защищать свой… способ… Хабр… модно ругать,

    глаза на лоб еще сильнее

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

    остается только надеяться, что большая часть посетителей Хабра — все еще способна без особых усилий понять, что такое «во1х», отличает пояснения от оправданий, иронию от ругани, итд итп

    и потому и не пишет ничего, слава Кришне, в эту замечательную подветку ;)
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
  • –7
    Ошибся в обоих пунктах, увы!
    1) пишется в 3 клика, а не 2, ибо скобки набираются с зажатым shift.
    2) чтение в 1000 раз быстрее пробенчмаркано только на одной платформе; на моей микроархитектуре различий нет, все исполняется за одинаковое время.

    А если серьезно, от всей этой ветки обсуждения у меня глаза слегка на лоб.

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

    Технический (вроде) ресурс, техническая (точно) статья, оформлена в целом, простите, не сказать, чтобы нечитаемо — а обсуждаем варианты написания «во-первых» — а еще 4 опечатки, которые я только что заодно с этим Чудовищным Отклонением от ХаброНормы исправил, не заметил почему-то никто.

    Привет, дивный новый Хабр — чую, еще пара лет эволюции в этом направлении и если хоть одну запятую не там поставишь, то берегись! Буря, пусть сильнее грянет буря!!! :)
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
  • +1
    Случится. Такое же, как в исходной версии.

    __m128i tmp1 = _mm_mul_epu32(a,b); /* mul 2,0*/
    __m128i tmp2 = _mm_mul_epu32( _mm_srli_si128(a,4), _mm_srli_si128(b,4)); /* mul 3,1 */
    return _mm_unpacklo_epi32(_mm_shuffle_epi32(tmp1, _MM_SHUFFLE (0,0,2,0)), _mm_shuffle_epi32(tmp2, _MM_SHUFFLE (0,0,2,0))); /* shuffle results to [63..0] and pack */
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
  • 0
    В идеале неплохо бы еще на разных архитектурах. Однако 250±200 это от 50 до 450, какой-то очень лихой разброс.
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
  • –10
    никогдааа?! 4 кнопки вместо 9, одна из которых чутка удаленный минус; в скайп-чатике быстрей-быстрей как же еще писать!? :)
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое
  • –4
    Щаз (*) соберется критическая масса опечаток и я на утеху grammar nazi поправлю, может, пост

    Но это сейчас у меня лично первый раз в жизни, когда кто-то не понял, что значит «во1х», «во2х», итп :)

    (*) авторская транскрипция; автор в курсе, что в словаре пишут «сейчас»; заранее спасибо, неизвестный кэп ;)
    Про мнимые и реальные оптимизации в 10 раз, целительный SSE, и все такое