Интересует мнение авторов, какие значения F-score, исходя из вашего опыта, сейчас считаются приемлемыми для бизнеса, для того чтобы использовать ML-решение?
В вашем примере наилучшее решение выдало F~0,69, действительно ли это устраивает заказчика?
Нет, это не так: https://msdn.microsoft.com/en-us/library/mt708821.aspx
Вы даёте ссылку на документацию к VC 2015, а тут вроде бы речь идёт про 2010. Если бы речь шла про 2015, то проблемы вообще бы не было, просто потому, что у компилятора есть соответствующая опция /utf-8, ссылку на которую Вы и даёте.
MSVS кодирует «узкие» строки в кодировку локали: https://msdn.microsoft.com/en-us/library/mt589696.aspx.
Там же написано следующее
The basic execution character set and the basic execution wide-character set consist of all the characters in the basic source character set...
Ну а про basic source character set сказано так
When source files are saved by using a locale-specific codepage or a Unicode codepage, Visual C++ allows you to use any of the characters of that code page in your source code
Т.е. Microsoft явно разрешает использовать все символы юникода в исходниках.
Вы не подумаете, что я сильно придираюсь, просто хочу понять, есть ли проблема на самом деле и как её воспроизвести. Собрал только что тестовый консольный проект в VC2010, сохранил исходники в utf-8, создал в коде узкую строку на традиционном китайском языке и никаких проблем с ней не обнаружил.
есть возможность написания строковых констант на русском языке в коде
…
Второе требование в случае UTF-8 не выполняется, к примеру, в MSVC 2010, где строковые константы кодируются в Windows-1251.
Мне кажется, Вы здесь вводите в заблуждение читателей. Строковые константы в UTF-8 прекрасно работают в MSVC 2010. Вам просто нужно превсести все ваши *.h и *.cpp файлы в UTF-8 без BOM и забыть о проблеме с кодировками. Ну и настроить среду так, чтобы новые исходники автоматом создавались в UTF-8.
Кроме этого, если вы реально планируете активно работать с многоязычными текстами, то, на мой взгляд, следовало сразу отказаться от вашего первого требования:
фиксированная ширина символов — возможен произвольный доступ к символу по его индексу
Из-за него вы перешли на UTF-32, а это большой оверхед. При том, что доступ к символам по их индексам на практике — не такая уж и частая задача. Большинство задач, связанных со строками, можно свести к их обходу с помощью итераторов.
Ещё один вопрос возник по поводу частичных индексов. Правильно ли я понял, если в таблице встречается высокочастотное значение, оно просто не добавляется в индекс? При этом, когда происходит выборка по этому значению делается обход таблицы и возвращаются все строки, которых нет в индексе?
Ещё в статье не совсем понятно написано про битовые карты. Как я понял из статьи, метод доступа возвращает множество TID, по которым можно просто пройтись и прочитать значения соответствующих строк, предварительно проверяя их видимость. Зачем в этой схеме отдельно строить карту? Ведь чтобы построить карту, нужно как минимум сделать точно такой же проход, чтобы проверить каждую строку на предмет видимости и проставить в соответствии с этим единичку в битовой карте. Получается для построения битовой карты нужно пройтись один раз по страницам таблицы. А потом, при непосредственном обходе карты, сделать это ещё раз при выборке целевых значений. Поясните, пожалуйста, как всё-таки на самом деле происходит работа с картами и за счёт чего в итоге получается выигрыш.
Ещё в статье не совсем понятно написано про битовые карты. Как я понял из статьи, метод доступа возвращает множество TID, по которым можно просто пройтись и прочитать значения соответствующих строк, предварительно проверяя их видимость. Зачем в этой схеме отдельно строить карту? Ведь чтобы построить карту, нужно как минимум сделать точно такой же проход, чтобы проверить каждую строку на предмет видимости и проставить в соответствии с этим единичку в битовой карте. Получается для построения битовой карты нужно пройтись один раз по страницам таблицы. А потом, при непосредственном обходе карты, сделать это ещё раз при выборке целевых значений. Поясните, пожалуйста, как всё-таки на самом деле происходит работа с картами и за счёт чего в итоге получается выигрыш.
Проблема разрастания индексов есть, и связана она не только с очисткой (как в случае таблицы), но и с тем, что индексные страницы могут при необходимости разбиваться на две, но не умеют срастаться обратно.
Вообще-то в B-деревьях склеивание разряжённых блоков — дело обычное. Неужели это не реализовано в PostgreSQL?
Мне были нужны районы городов, чтобы стоимость доставки считать...
Подскажите, а в каких городах РФ стоимость доставки зависит от района города? Я сам в Москве живу, и где бы я не находился, доставка мне всегда обходится в 300 рублей, независимо от района. Вопрос без иронии, просто хочу понять, насколько ваш кейс распространён.
А по существу вашего вопроса, я не понял какое отношение расчёт стоимости доставки имеет к тому, что пользователь видит в подсказках? Выше я написал про избыточность информации, которая мешает пользователю искать свой адрес. Вот давайте вернемся к примеру с «городом Березовский», покупатель видит подсказку для него «г Краснодар, Березовский сельский р-н». Сколько пользы получит он от такой подсказки?
Что значит «чаще всего»? :) Много кто доставляет по всей России, потому что отправляет товар почтой по всей России. Будем предлагать пользователю выбрать город руками?
Я сослался на пример про пиццу, как на пример местечкового магазина, который не рассчитывает продавать продукцию в соседние города. Мне кажется, что таких маленьких магазинов по статистике больше, чем крупных, которые ориентированы на охват всей России. Возможно, я ошибся, если у вас есть иная статистика, приношу извинения. Ну а касательно крупных магазинов, в которых пользователь заказывает из другого города, то, на мой взгляд, проблемы указать свой город явно здесь нет. Цена вопроса, вроде бы, две-три буквы. Наоборот, пользователь видит явно свой город, его уверенность в том, что он делает всё правильно растёт. Это, конечно, вопрос юзабилити и здесь важно мнение конечных пользователей. Тем не менее, мне кажется, это лучше, чем получать «проезд Мирный 2-ой» вместо «города Мирный».
То есть вы мне под предлогом «избыточности» отдаете куцые данные, а если мне надо больше данных – предлагаете для решения задачи юзать ваше платное API стандартизации адресов
Здесь каждый для себя выбирает сам. Либо вы платите за подсказки, либо платите за проверку адресов в уже оформленных заказах.На Ахантере вам не надо платить за подсказки и не играет никакой роли, в каком количестве ваши покупатели нащёлкают их у вас на сайте. Да, в нашем случае вам придётся заплатить 10 копеек за получение координат и прочей информации об адресе. Но заказ-то уже оформлен, неужели 10 копеек сильно снизят вашу прибыль от него?
Можно узнать, как? Мне вот ваше API Подсказок отдает пустой ответ на «санкт-петербург ул 2 жерновская д 26».
Вот так у нас на сайте выглядит ввод вашего адреса.
Как видно, подсказки появляются без проблем. После выбора вашей улицы просто вбейте номер дома в конце строки. Подсказки для номеров домов вы там не увидите, т.к. мы считаем их бесполезными, поскольку полагаем, что человек больше времени тратит на поиск и выбор своего дома в предложенном списке. Я об этом выше написал. Если у вас есть другой опыт, поделитесь, пожалуйста, а мы со своей стороны охотно добавим этот функционал в наш сервис.
Мы в Ахантере не стали вываливать в подсказки кучу дополнительной информации, о которой вы пишите, т.к. считаем, что пользы от неё именно в подсказках нет.
Вот, например, какая польза от того, что человек в подсказках увидит индекс и район города? Это ведь лишняя информация, которая только мешает человеку искать среди подсказок свой адрес. Подсказка должна быть предельно лаконичной, именно тогда от неё будет польза.
Координаты, индекс и прочую информацию об адресе можно получить уже после того, как пользователь завершит вводить адрес. Для этого у нас есть отдельное API. Собственно также можно поступать, используя другие сервисы, о которых здесь написано.
По поводу «локальных адресов», чаще всего магазины доставляют по своему городу, вряд ли вы будете пиццу заказывать во Владивостоке. В этом случае правильнее не рассчитывать на геолокацию по IP-адресу, а просто зашить ограничение на город в самом интернет-магазине. Это можно сделать с любым из рассмотренных сервисов. Гораздо хуже, как мне кажется, когда в подсказках вместо «города Березовский» вываливается «Березовский сельский р-н». Не понятно, почему вы это позиционируете, как фичу?
По поводу номеров домов и квартир. Вы серьезно считаете, что человеку нужны подсказки для его дома и квартиры? Выше я написал про лаконичность, на мой взгляд, когда перед пользователем вываливается избыточная информация, он начинает отвлекаться на неё, как результат одну-две цифры своего номера он вводит дольше с подсказками, чем без них. Интересно, у вас есть свои оценки полезности подсказок для домов, можете их привести? Может быть мы тогда тоже добавим эту возможность у себя.
Ну а возможность ввести адрес одной строкой есть, вроде бы, у всех сервисов, про которые тут сказано. По крайней мере, в Ахантере вводить дом и кваритру в одну строку с адресом можно без проблем, поэтому с «минимизацией лишних телодвижений для человека» тут полный порядок.
epoll возвращает список сокетов, в которых готовы данные для чтения. Вопрос в том, каким образом одним системным вызовом можно выполнить чтение из нескольких готовых сокетов? Традиционный recv позволяет прочитать данные только из одного сокета.
1. Подскажите, почему для тестов взят unordered_map, вместо обычного map? В индексах СУБД часто используются деревья, поэтому пример с map-ом был бы более репрезентативным.
2. Подскажите, почему был выбран именно такой тест? Какое поведение СУБД он моделирует?
for (int i = 0; i < SIZE;++i)
c += m[i*i] += i;
3. Не до конца понятно, как технически реализуется групповое чтение запросов из сокета. Ведь в традиционной схеме сервер устанавливает с клиентом соединение, для чего на стороне сервера создается индивидуальный для конкретного клиента сокет, из которого сервер читает запрос и куда сервер пишет ответ. В такой схеме не получится организовать групповое чтение. Можете подсказать, какая техника работы с сокетом в данном случае предлагается.
Подскажите, а какие исходники Вы бы хотели здесь увидеть?
На счет «не нашел для себя ничего нового», видимо, у Вас, действительно, богатый опыт, с интересом ознакомлюсь с аналогичными материалами, если Вы скинете на них ссылки.
Часто для этого используется БД. В нашем случае такой подход нивелировал бы всю оптимизацию, поэтому делается разделение между API-сессиями и GUI-сессиями. API-сессия запускается на каждом сервере независимо при получении от клиентского приложения первого запроса. Все изменения в аккаунте пользователя, которые происходят из-за активности API-сессии, реплицируются между серверами асинхронно. Проблемы, которые могут возникнуть в результате такой асинхронности, в каждом конкретном случае решаются отдельно. Например, на двух серверах пользовательский баланс может независимо дойти до нуля. В этом случае при репликации он на обоих серверах корректируется и становится отрицательным. Однако API-функции подсказок, которым посвящена данная статья, изменения в аккаунте не производят. Это открытая функций, по ней даже статистика не фиксируется, поэтому тут даже репликация между серверами не требуется.
Оптимизацию на стороне клиента можно делать независимо от серверной части, в том числе, и так, как вы предлагаете. Однако подсказки в этом случае будут менее адекватными. Дело в том, что всякий раз, когда пользователь вводит новый символ, вся введенная строка проходит полный цикл обработки на сервисе, который включает в себя ранжирование вариантов перед их выдачей. При ранжировании для каждого варианта оценивается вероятность того, что он будет полезным для пользователя. При ранжировании учитывается как информация, введенная пользователем к настоящему моменту, так и априорная информация об адресных объектах (их размер, популярность и пр.). Если на каком-то этапе ввода не отсылать строку на сервис, а брать варианты, которые вернул сервис ранее, то будет использоваться неадекватный результат ранжирования, полученный при вводе более короткой строки. Ну или придется реализовать повторное ранжирование на стороне клиента.
CAS, к сожалению, не удалось посмотреть. По части CTPP — его исходники удалось весьма детально изучить. В частности при разработке собственного шаблонизатора мы заимствовали оттуда идею представления данных, передаваемых шаблону.
На скриншоте вывел загрузку процессора для приложения, сервера обработки и вебсервера при потоке запросов от одного пользователя.
Процесс «api» — это приложение, «lighttpd» — это вер-сервер.
Сервер обработки запущен от root, просьба не пинать за это, т.к. он запущен по-быстрому чисто для теста.
На картинке видно, что приложение отъедает 45,6% CPU.
В старой архитектуре кэш был реализован на стороне сервера обработки. Там сконцентрированы все вычисления и работа с данными, поэтому там можно было кэшировать не просто ответы, но также результаты промежуточных вычислений. Но описанную в статье проблему этот кэш не решал, т.к. задержки возникали не доходя до него. Нужно было организовывать еще один кэш на стороне приложения или веб-сервера, но этого мы делать не стали, т.к. посчитали, что кэшировать в двух местах фактически одни и те же данные — достаточно дорого по ресурсам.
По поводу перехода на lua, если бы мы разрабатывали с нуля новый сервис, то у нас было бы больше вариантов для выбора архитектуры. Здесь же имел место рефакторинг унаследованного сервиса, у которого именно алгоритмическая часть, отвечающая за обработку данных, уже была оптимизирована (для этого в старой архитектуре вся эта обработка была оформлена в виде сервера на С++). Всю эту реализацию хотелось не переписывать заново, а аккуратно перенести в новую архитектуру.
В вашем примере наилучшее решение выдало F~0,69, действительно ли это устраивает заказчика?
Вы даёте ссылку на документацию к VC 2015, а тут вроде бы речь идёт про 2010. Если бы речь шла про 2015, то проблемы вообще бы не было, просто потому, что у компилятора есть соответствующая опция /utf-8, ссылку на которую Вы и даёте.
Там же написано следующее
Ну а про basic source character set сказано так
Т.е. Microsoft явно разрешает использовать все символы юникода в исходниках.
Вы не подумаете, что я сильно придираюсь, просто хочу понять, есть ли проблема на самом деле и как её воспроизвести. Собрал только что тестовый консольный проект в VC2010, сохранил исходники в utf-8, создал в коде узкую строку на традиционном китайском языке и никаких проблем с ней не обнаружил.
Этот код у меня на экран консоли выдаёт цифру 6
Мне кажется, Вы здесь вводите в заблуждение читателей. Строковые константы в UTF-8 прекрасно работают в MSVC 2010. Вам просто нужно превсести все ваши *.h и *.cpp файлы в UTF-8 без BOM и забыть о проблеме с кодировками. Ну и настроить среду так, чтобы новые исходники автоматом создавались в UTF-8.
Кроме этого, если вы реально планируете активно работать с многоязычными текстами, то, на мой взгляд, следовало сразу отказаться от вашего первого требования:
Из-за него вы перешли на UTF-32, а это большой оверхед. При том, что доступ к символам по их индексам на практике — не такая уж и частая задача. Большинство задач, связанных со строками, можно свести к их обходу с помощью итераторов.
Вообще-то в B-деревьях склеивание разряжённых блоков — дело обычное. Неужели это не реализовано в PostgreSQL?
А по существу вашего вопроса, я не понял какое отношение расчёт стоимости доставки имеет к тому, что пользователь видит в подсказках? Выше я написал про избыточность информации, которая мешает пользователю искать свой адрес. Вот давайте вернемся к примеру с «городом Березовский», покупатель видит подсказку для него «г Краснодар, Березовский сельский р-н». Сколько пользы получит он от такой подсказки?
Я сослался на пример про пиццу, как на пример местечкового магазина, который не рассчитывает продавать продукцию в соседние города. Мне кажется, что таких маленьких магазинов по статистике больше, чем крупных, которые ориентированы на охват всей России. Возможно, я ошибся, если у вас есть иная статистика, приношу извинения. Ну а касательно крупных магазинов, в которых пользователь заказывает из другого города, то, на мой взгляд, проблемы указать свой город явно здесь нет. Цена вопроса, вроде бы, две-три буквы. Наоборот, пользователь видит явно свой город, его уверенность в том, что он делает всё правильно растёт. Это, конечно, вопрос юзабилити и здесь важно мнение конечных пользователей. Тем не менее, мне кажется, это лучше, чем получать «проезд Мирный 2-ой» вместо «города Мирный».
Здесь каждый для себя выбирает сам. Либо вы платите за подсказки, либо платите за проверку адресов в уже оформленных заказах.На Ахантере вам не надо платить за подсказки и не играет никакой роли, в каком количестве ваши покупатели нащёлкают их у вас на сайте. Да, в нашем случае вам придётся заплатить 10 копеек за получение координат и прочей информации об адресе. Но заказ-то уже оформлен, неужели 10 копеек сильно снизят вашу прибыль от него?
Вот так у нас на сайте выглядит ввод вашего адреса.
Как видно, подсказки появляются без проблем. После выбора вашей улицы просто вбейте номер дома в конце строки. Подсказки для номеров домов вы там не увидите, т.к. мы считаем их бесполезными, поскольку полагаем, что человек больше времени тратит на поиск и выбор своего дома в предложенном списке. Я об этом выше написал. Если у вас есть другой опыт, поделитесь, пожалуйста, а мы со своей стороны охотно добавим этот функционал в наш сервис.
Чисто из любопытства, подскажите сколько дней вам потребовалось, чтобы выполнить тест для Google с учётом обозначенных квот?
Вообще по всем сервисам интересно, удалось ли уложиться в лимиты или тест длился несколько дней?
Вот, например, какая польза от того, что человек в подсказках увидит индекс и район города? Это ведь лишняя информация, которая только мешает человеку искать среди подсказок свой адрес. Подсказка должна быть предельно лаконичной, именно тогда от неё будет польза.
Координаты, индекс и прочую информацию об адресе можно получить уже после того, как пользователь завершит вводить адрес. Для этого у нас есть отдельное API. Собственно также можно поступать, используя другие сервисы, о которых здесь написано.
По поводу «локальных адресов», чаще всего магазины доставляют по своему городу, вряд ли вы будете пиццу заказывать во Владивостоке. В этом случае правильнее не рассчитывать на геолокацию по IP-адресу, а просто зашить ограничение на город в самом интернет-магазине. Это можно сделать с любым из рассмотренных сервисов. Гораздо хуже, как мне кажется, когда в подсказках вместо «города Березовский» вываливается «Березовский сельский р-н». Не понятно, почему вы это позиционируете, как фичу?
По поводу номеров домов и квартир. Вы серьезно считаете, что человеку нужны подсказки для его дома и квартиры? Выше я написал про лаконичность, на мой взгляд, когда перед пользователем вываливается избыточная информация, он начинает отвлекаться на неё, как результат одну-две цифры своего номера он вводит дольше с подсказками, чем без них. Интересно, у вас есть свои оценки полезности подсказок для домов, можете их привести? Может быть мы тогда тоже добавим эту возможность у себя.
Ну а возможность ввести адрес одной строкой есть, вроде бы, у всех сервисов, про которые тут сказано. По крайней мере, в Ахантере вводить дом и кваритру в одну строку с адресом можно без проблем, поэтому с «минимизацией лишних телодвижений для человека» тут полный порядок.
2. Подскажите, почему был выбран именно такой тест? Какое поведение СУБД он моделирует?
3. Не до конца понятно, как технически реализуется групповое чтение запросов из сокета. Ведь в традиционной схеме сервер устанавливает с клиентом соединение, для чего на стороне сервера создается индивидуальный для конкретного клиента сокет, из которого сервер читает запрос и куда сервер пишет ответ. В такой схеме не получится организовать групповое чтение. Можете подсказать, какая техника работы с сокетом в данном случае предлагается.
На счет «не нашел для себя ничего нового», видимо, у Вас, действительно, богатый опыт, с интересом ознакомлюсь с аналогичными материалами, если Вы скинете на них ссылки.
Процесс «api» — это приложение, «lighttpd» — это вер-сервер.
Сервер обработки запущен от root, просьба не пинать за это, т.к. он запущен по-быстрому чисто для теста.
На картинке видно, что приложение отъедает 45,6% CPU.
По поводу перехода на lua, если бы мы разрабатывали с нуля новый сервис, то у нас было бы больше вариантов для выбора архитектуры. Здесь же имел место рефакторинг унаследованного сервиса, у которого именно алгоритмическая часть, отвечающая за обработку данных, уже была оптимизирована (для этого в старой архитектуре вся эта обработка была оформлена в виде сервера на С++). Всю эту реализацию хотелось не переписывать заново, а аккуратно перенести в новую архитектуру.