После экспериментов со склонениями и спряжениями разных слов мне показалось, что Мэйл в морфологии разбирается лучше остальных.
Спасибо! Кстати, скоро станет еще лучше. Активно работаем над морфологией. :)
Но, в отличие от Яндекса с Gmail, здесь не выводится общее количество найденных писем.
Выводится, если больше одной страницы результатов.
Цифры в составе слов (3-й образец) найти не смог никто.
А это будет. Токенизацию тоже существенно улучшаем.
Эта же логика наблюдается и при поиске частей слов: ищется только слово целиком, по отдельным частям не работает.
К сожалению, нельзя сделать эффективно. Размер словаря по экспоненте вырастет. Поэтому, никто и не умеет. Подробнее по устройству поиска можно тут глянуть: habrahabr.ru/company/mailru/blog/167497
Со времен публикации много улучшилось, но суть осталась таже.
Тут не работает поиск чисел по таблицам Excel ни в старом формате XLS, ни в новом XLSX:
А вот это уже и правда баг. И мы его уже фиксим.
Понятно, что в приоритете стоят задачи, которые увеличивают прибыль компании и найденный баг к этой категории не относится, но надеюсь, что Mail.Ru когда-нибудь пофиксит и его.
Это не так. Баги всегда имеют приоритет перед любыми фичами. Проблемой мы уже занимаемся и скоро пофиксим.
Но на счет «чем-то» отличается, у меня достаточно много скептицизма тут.
Аппеляция к личности автора, к сожалению, вряд ли можно считать за существенное отличие. Ну а в плане техники… все-таки, глобально, это всего лишь «еще одно доказательство в списке». Потому что у всех 116 тоже есть что-то отличное в технике.
Думаю, поднимать хайп пока еще очень и очень рано.
Да, было дело. Я по сути рассказывал ровно то, что рассказывал уже упомянутый тут Robert Sedgewick в своей книге и в своем курсе на Coursera. Очень советую как первоисточник.
Мне действительно жаль, что у вас возникло такое ощущение, хотя я такого и не заявлял. Тем не менее, мой юзкейс чрезвычайно часто встречается в реальном мире, и именно этом обоснован мой выбор.
Все-таки наличие тестирования не подразумевает тестирование ВСЕХ случаев.
Тестировать можно по-разному: синхронно, асинхронно, синхронно-асинхронно, с батчингом и без него, с хранилками.
Но все и сразу — нет. Это будет месиво информации, которое бросят читать на полпути.
Я уже делал тест с батчингом (правда, асинхронный) и демонстрировал его результаты на хайлоаде.
Тут я захотел сделать тест без батчинга — по этой причине. Кратко — я взял типовой, по моему мнению, профиль нагрузки и сделал тест под нему.
На batch-режим есть одна достаточно серьезная претензия.
Он совершенно не всегда может быть органически встроен в структуру проекта.
Придется писать дополнительный код, который эти пачки формирует.
То есть в теории, конечно, попробовать можно протестировать, но а практике не факт что этот подход будет легко применим, ИМХО.
То есть нам важно не «сколько из СУБД можно выжать в принципе» (сферический конь в вакууме), а сколько можно выжать на типовой бизнесовой задаче.
+ Делая пачку, мы увеличиваем latency для первых запросов в ней. (!)
Был бы рад с вами пообщаться на эту тему, если вы не против.
Хочу «разогнать» VoltDB и перечертить графики, но пока это лучшее, что удалось на таком тесте.
Теперь точно, проблема на производстве.
А вот по OpenOffice пока на ближайшее время не планировали, то есть точно не в этом году. :( А далее посмотрим, возможно все.
Спасибо! Кстати, скоро станет еще лучше. Активно работаем над морфологией. :)
Выводится, если больше одной страницы результатов.
А это будет. Токенизацию тоже существенно улучшаем.
К сожалению, нельзя сделать эффективно. Размер словаря по экспоненте вырастет. Поэтому, никто и не умеет. Подробнее по устройству поиска можно тут глянуть: habrahabr.ru/company/mailru/blog/167497
Со времен публикации много улучшилось, но суть осталась таже.
А вот это уже и правда баг. И мы его уже фиксим.
Это не так. Баги всегда имеют приоритет перед любыми фичами. Проблемой мы уже занимаемся и скоро пофиксим.
Но на счет «чем-то» отличается, у меня достаточно много скептицизма тут.
Аппеляция к личности автора, к сожалению, вряд ли можно считать за существенное отличие. Ну а в плане техники… все-таки, глобально, это всего лишь «еще одно доказательство в списке». Потому что у всех 116 тоже есть что-то отличное в технике.
Думаю, поднимать хайп пока еще очень и очень рано.
P.S. А эта статья так себе, я ничего не понял. :(
P.S. Особенно порадовал первый диалог со спамером, в котором сочетаются:
и
А еще есть C API, с помощью которого вы можете внедрить любой язык. :)
Тестировать можно по-разному: синхронно, асинхронно, синхронно-асинхронно, с батчингом и без него, с хранилками.
Но все и сразу — нет. Это будет месиво информации, которое бросят читать на полпути.
Я уже делал тест с батчингом (правда, асинхронный) и демонстрировал его результаты на хайлоаде.
Тут я захотел сделать тест без батчинга — по этой причине. Кратко — я взял типовой, по моему мнению, профиль нагрузки и сделал тест под нему.
Потому что я всегда пишу тесты под задачу. Сегодня выбрал такую.
Батчинг — интересная тема, но для совсем другого теста.
В целом этот тест больше для «масс-маркета», чем тест с батчингом.
Основная же идея — сравнивать равное.
Он совершенно не всегда может быть органически встроен в структуру проекта.
Придется писать дополнительный код, который эти пачки формирует.
То есть в теории, конечно, попробовать можно протестировать, но а практике не факт что этот подход будет легко применим, ИМХО.
То есть нам важно не «сколько из СУБД можно выжать в принципе» (сферический конь в вакууме), а сколько можно выжать на типовой бизнесовой задаче.
+ Делая пачку, мы увеличиваем latency для первых запросов в ней. (!)
Там цель была не в сравнении, а показать, что при синхронном тесте мы упираемся в потолок раньше.
Но раз вопрос возник — попробую нарисовать — покажу.
Хочу «разогнать» VoltDB и перечертить графики, но пока это лучшее, что удалось на таком тесте.
Но я там красоту не наводил, выложил AS IS.