• А вот про Sphinx 3.0
    0
    Да меня в целом в текущей ситуации многое «смущает», в том числе и этот момент. Это не самая большая головная боль.

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

    Замечу ещё, что доступ к исходникам там, где можно и нужно, я тоже обеспечиваю и тоже уже сейчас.
  • А вот про Sphinx 3.0
    +1
    Да у меня пока ещё нет желания тратить время на онлайн-драму и постить все пикантные и феерические подробности. Глобально-то история довольно банальная: начались разные проблемы, люди довольно некрасиво форкнулись, люди довольно некрасиво ушли, люди продолжают делать странные и некрасивые вещи, чем местами тупо мешают и проекту Сфинкс и лично мне.

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

    При этом погонять 3.0 можно прямо сейчас, нужно написать мне в почту и я выдам билд.
  • Андрей Карпов считает, что код проекта Manticore качественнее, чем код проекта Sphinx
    +1
    У нас явно разные понятия «красоты» — это не красивая в моём личном понимании — это скучный и тупой off-by-one классический.

    Последнюю именно «красивую» ошибку даже и не вспомню навскидку. Первое и последнее, что моментально приходит в голову — в итоге оказалось вообще не в C++ коде совсем :)
  • Андрей Карпов считает, что код проекта Manticore качественнее, чем код проекта Sphinx
    +4
    отсутствие проверок на ошибочные данные было/стало скорее фичёй

    Нет, это не совсем так.


    Концепция всегда была (и есть) следующая:


    • Если можно "почти бесплатно" не падать на кривом входе, следует не падать.
    • Если это дорого, делаем утилиты для проверок (это и assert, и indextool, и т.д.), но сохраняем производительность.

    Причём про "вход" тут речь вообще-то в первую очередь скорее о данных индекса, чем пользовательском вводе. Пользовательскому как раз веры почти (почти) никакой, проверяем его что есть сил, где не забываем. Одно хорошо: что не вебсервер, и редко голым поротом в интернет смотрим, типично хотя бы в VPN.


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

  • А вот про Sphinx 3.0
    0
    Не, эти «люди» форкнулись по решительно другим причинам, настоящая история (в отличие от официальной) совершенно феерическая.

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

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

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

  • ElasticSearch и поиск наоборот. Percolate API
    0
    summon сработал, а вопрос-то в чем? :)

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

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

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

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

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

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

    и потому и не пишет ничего, слава Кришне, в эту замечательную подветку ;)