Pull to refresh
401
0
Andrew Aksyonoff @shodan

User

Send message
1. Инструмент сразу был дрянненький вообще-то, и предназначлся скорее для внутренней отладки. Заменой, как всегда, является штатный запуск searchd и запросы либо через mysql либо любой другой удобный клиент.

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

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

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

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

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

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

С одной стороны «хотите отсортировать выдачу по количеству просмотров документа», с другой «записывать каждый просмотр в 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: поправил опечатки.
Оно доступно в 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"],
    ...
}
Да, отключаемо (или не включаемо, пока не решил, какой лучше дефолт).
— это что? Где можно почитать?

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

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

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

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

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

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

summon сработал, а вопрос-то в чем? :)

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

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

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

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

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

Плюс автомат с суффиксами ловко угадывает леммы для неизвестных слов, с хешами тоже можно, но реализация прикидочно помуторнее.
Если бы все было понятно по слайдам, я был бы не нужен!!!
Я даже специально написал!
Бесплатный VS Express, cl /EHsc nanomysql.cpp и должно работать.

Information

Rating
Does not participate
Works in
Registered
Activity