Тоже участвовал в этом конкурсе, но в привате оказался только на 80-м месте с результатом 75.67%.
Схема работы с данными приблизительно такая же. Отчистка данных, предварительные прогоны по xgb/glm/nn, анализ предикторов с высоким показателем важности. Была попытка генерации доп-фич в виде CTR для каждой пары класс-предиктор для ряда хорошо показавших себя предикторов. На тестовой выборке доп. фичи скорее мешали, чем помогали. Поэтому были исключены. Но благодаря им была найдена взаимосвязь между предикторами x55-60 и финальным классом. Так же обнаружилось, что каждый класс помимо самых жирных предикторов вроде x8 или x29/x30 наилучшим образом предсказывался своим набором предикторов и поэтому была сделана модель на основании xgboost, предсказывающая каждый класс в отдельности и потом делающая свёртку с коррекцией весов для каждого класса. В конечном итоге упёрся в те самые 25% выборки, которые по моим выводам предсказать было невозможно. Видимо, это те самые пенсионеры, покупающие молодёжные тарифы в подарок внучке :) И, судя по финальному месту, просто не хватило времени/терпения чтобы сделать тонкую настройку модели.
У меня был похожий кейс на одном из проектов. Требовалось сохранить 10+ миллиардов туристических предложений. В качестве основного хранилища был выбран Solr. Почему именно он — вопрос второй. Суть в том, что помимо сохранения информации, нужно было вести историю изменения цен (редкие апдейты) и актуализировать наличие авиарейсов по каждому из миллиардов предложений в момент запроса для фильтрации и аналитики.
В итоге, апдейты цен с историей делались через самописанный модуль к Solr. Операция была тяжёлая из-за append-only архитектуры, но требования позволяли. Актуализация авиарейсов — это был крайне интересный хардкор. Рейсы хранились в кластере Redis. Информация по наличию мест и их количеству обновлялась практически в реалтайме. Чтобы это всё жило, я запилил несколько кастомных типов данных, которые использовались в схеме и просчитывались в реалтайме. При старте нод Solr делался прогрев внутреннего кеша инфой из Редиса. Памяти было много, можно было себе позволить.
Особый треш был в том, что всё это должно было работать на 100 шардах помноженных на коэффициент репликации. Плюс круглосуточный входной поток данных.
Я наслышан о нареканиях на Хецнеровские сервера, за три года использования через меня прошёл десяток серверов и всё было в порядке. Быть может мне повезло… :)
И теперь победитель во всех категориях… Тадам!
Цена — 66,39 € для кастомеров из России
Intel® Xeon® E3-1270 v3
Quad-Core Haswell
RAM — 32 GB ECC RAM
Hard Drive — 2 x 240 GB SATA 6 Gb/s Data Center Series SSD (Software-RAID 1)
Connection — 1 Gbit/s-Port
Guaranteed Bandwidth — 200 Mbit/s
Backup Space — 100 GB
Inclusive Traffic — 30 TB http://ru.hetzner.com/hosting/produkte_rootserver/px60ssd
Там вообще нет обрезки тегов. Все аргументы ескейптся с помощью мускульной функции. В базу попадает уже отъескепленный текст любого размера. И уже база делает отлуп превышения размерности.
Коммит — очередной костыль, к XSS не имеющий никакого отношения.
А это вообще шедевр
public function escape_by_ref( &$string ) {
if ( ! is_float( $string ) )
$string = $this->_real_escape( $string );
}
Вас удовлетворит, если я скажу, что все проблемы с целостностью данных которые встречались нам были связаны с ошибками приложения-писателя, и ни разу не было проблем, связанных с libslave?
Ну тут не в удовлетворении дело… :) Меня просто интересуют сложные ситуации на продакшене. Вот и докапываюсь, откуда ноги растут, наступившие и победившие грабли.
По поводу CHECK я понял. Хоть это и не имеет отношения конкретно к ссылочной целостности, но мы точки на i расставили. Спасибо.
Вы ошибаетесь. Подробней читайте тут: habrahabr.ru/company/mailru/blog/219015/
Если я всё правильно понял из статьи, то там прямо говорится, что Бегун запилил свой libslave, занимающийся разбором бинлога, под свои узкопрофильные задачи, и что проверка консистентности данных проводится демоном потому что «Заметим, что на этапе первоначальной выборки данных их неконсистентность не говорит о том, что ошибки присутствуют в базе — просто это такая особенность процесса загрузки данных. Такая неконсистентность будет исправлена далее демоном при дочитывании данных. А вот если после этого в них есть какие-то несоответствия — тогда уже да, тогда это база.»
Проблема именно в том, что в MySQL вставляют некорректные данные, и в нём нету возможности запретить такие данные вставлять.
Затем, что проекты сидящие на 5.5 часто используют одновременно MyISAM таблицы для полнотекстового поиска и InnoDB таблицы для всего остального.
Низкопроизводительный костыль, нет?
Да, тот самый пресловутый CHECK, без которого в сложных проектах жизнь становится горькой
CHECK отсутствует, но легко реализуем через триггеры.
Остальные «constraint'ы общего вида» в MySQL присутствуют из коробки и вполне работоспособны. dev.mysql.com/doc/refman/5.6/en/create-table.html
Он не может загрузить таргетинги, например, если в таргетингах кривая косвенная ссылка на баннер или кампанию — т.е. демон обнаруживает неконсистентность данных, и в такой ситуации рапортует о ней.
Вангую, что это не проблема проверки ссылочной целостности на уровне БД (foreign key запретили что ли?), а проблема рассинхрона данных в БД и их копии в памяти, из-за которой и пришлось городить костыли. К выбору MySQL/PostgreSQL никакого отношения не имеющая. Поправьте меня, если ошибаюсь.
Совершенно неочевидно. До, кажется, 5.6 в InnoDB не было полнотекстового поиска, а в 5.6 уже есть регрессия производительности репликации, потому многие сидят на 5.5
Мы обсуждали ссылочную целостность. Отсюда и контекст. При чём тут полнотекстовый поиск? Да и вообще для этих задач из опенсорса есть Solr/Elasticsearch/Sphinx. Всё остальное — зло.
Без поддержки table inheritance и constraint'ов общего вида проверять валидность таких ссылок можно лишь на уровне приложения, а это очень неудобно.
Начнём с того, что PostgreSQL изначально была Object-Relational DB. И её по фичам невозможно сравнивать с классической RDBMS.
Во-вторых, вопрос был в том, что именно из sql constraints (за исключением check) реализовано в PostgreSQL и отсутствует в MySQL или же реализовано «не достаточно»?
И какое это имеет отношение к ссылочной целостности?
Не в MySQL, а в InnoDB. И таких базовых проверок явно недостаточно.
То что в InnoDB в данном контексте это очевидно, думаю.
Не очевидно, каких именно проверок ссылочной целостности не хватает в Мускуле для полного счастья?
Один из наших демонов, работающий как slave к MySQL, мониторит ссылочную целостность
Можно чуть подробнее, что именно делает ваш демон?
В PostgreSQL практически все наши хотелки описываются через constraints общего вида.
Если речь идёт о CHECK, то это проверка не ссылочной целостности, а данных. При желании отлично решается через триггеры.
Всё остальное (not null, unique, foreign keys) реализовано в MySQL в рамках стандарта SQL-92.
Я имею в виду мэпинг физических файлов в память, входящий в стандарт posix и активно используемый Еластиком при работе с индексами при включенном mmapfs. Я не в курсе подробностей, умеет ли контейнер работать с этой фичей. По-верхам погуглил и ничего внятного не нашёл.
ЗЫ. Тому кто не понял вопрос и влепил минус отдельное спасибо.
3. Помимо индексирования текста документа используются дополнительные индексированные атрибуты: дата создания, категория, код, владелец/автор, etc?
4. Да, согласен про палец :) Задал вопрос, смотря на тему со своей колокольни. Среднюю температуру по больнице понял, спасибо!
Схема работы с данными приблизительно такая же. Отчистка данных, предварительные прогоны по xgb/glm/nn, анализ предикторов с высоким показателем важности. Была попытка генерации доп-фич в виде CTR для каждой пары класс-предиктор для ряда хорошо показавших себя предикторов. На тестовой выборке доп. фичи скорее мешали, чем помогали. Поэтому были исключены. Но благодаря им была найдена взаимосвязь между предикторами x55-60 и финальным классом. Так же обнаружилось, что каждый класс помимо самых жирных предикторов вроде x8 или x29/x30 наилучшим образом предсказывался своим набором предикторов и поэтому была сделана модель на основании xgboost, предсказывающая каждый класс в отдельности и потом делающая свёртку с коррекцией весов для каждого класса. В конечном итоге упёрся в те самые 25% выборки, которые по моим выводам предсказать было невозможно. Видимо, это те самые пенсионеры, покупающие молодёжные тарифы в подарок внучке :) И, судя по финальному месту, просто не хватило времени/терпения чтобы сделать тонкую настройку модели.
В итоге, апдейты цен с историей делались через самописанный модуль к Solr. Операция была тяжёлая из-за append-only архитектуры, но требования позволяли. Актуализация авиарейсов — это был крайне интересный хардкор. Рейсы хранились в кластере Redis. Информация по наличию мест и их количеству обновлялась практически в реалтайме. Чтобы это всё жило, я запилил несколько кастомных типов данных, которые использовались в схеме и просчитывались в реалтайме. При старте нод Solr делался прогрев внутреннего кеша инфой из Редиса. Памяти было много, можно было себе позволить.
Особый треш был в том, что всё это должно было работать на 100 шардах помноженных на коэффициент репликации. Плюс круглосуточный входной поток данных.
Цена — 66,39 € для кастомеров из России
Intel® Xeon® E3-1270 v3
Quad-Core Haswell
RAM — 32 GB ECC RAM
Hard Drive — 2 x 240 GB SATA 6 Gb/s Data Center Series SSD (Software-RAID 1)
Connection — 1 Gbit/s-Port
Guaranteed Bandwidth — 200 Mbit/s
Backup Space — 100 GB
Inclusive Traffic — 30 TB
http://ru.hetzner.com/hosting/produkte_rootserver/px60ssd
Коммит — очередной костыль, к XSS не имеющий никакого отношения.
А это вообще шедевр
Как, собственно, и весь ВП :)
Ну тут не в удовлетворении дело… :) Меня просто интересуют сложные ситуации на продакшене. Вот и докапываюсь, откуда ноги растут, наступившие и победившие грабли.
По поводу CHECK я понял. Хоть это и не имеет отношения конкретно к ссылочной целостности, но мы точки на i расставили. Спасибо.
Если я всё правильно понял из статьи, то там прямо говорится, что Бегун запилил свой libslave, занимающийся разбором бинлога, под свои узкопрофильные задачи, и что проверка консистентности данных проводится демоном потому что «Заметим, что на этапе первоначальной выборки данных их неконсистентность не говорит о том, что ошибки присутствуют в базе — просто это такая особенность процесса загрузки данных. Такая неконсистентность будет исправлена далее демоном при дочитывании данных. А вот если после этого в них есть какие-то несоответствия — тогда уже да, тогда это база.»
dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
Бажное(зарепорчено?)/не использовалось вообще/сливало данные в бинлог до проверки (зарепорчено?)?
Низкопроизводительный костыль, нет?
CHECK отсутствует, но легко реализуем через триггеры.
Остальные «constraint'ы общего вида» в MySQL присутствуют из коробки и вполне работоспособны.
dev.mysql.com/doc/refman/5.6/en/create-table.html
Вангую, что это не проблема проверки ссылочной целостности на уровне БД (foreign key запретили что ли?), а проблема рассинхрона данных в БД и их копии в памяти, из-за которой и пришлось городить костыли. К выбору MySQL/PostgreSQL никакого отношения не имеющая. Поправьте меня, если ошибаюсь.
Мы обсуждали ссылочную целостность. Отсюда и контекст. При чём тут полнотекстовый поиск? Да и вообще для этих задач из опенсорса есть Solr/Elasticsearch/Sphinx. Всё остальное — зло.
Начнём с того, что PostgreSQL изначально была Object-Relational DB. И её по фичам невозможно сравнивать с классической RDBMS.
Во-вторых, вопрос был в том, что именно из sql constraints (за исключением check) реализовано в PostgreSQL и отсутствует в MySQL или же реализовано «не достаточно»?
И какое это имеет отношение к ссылочной целостности?
То что в InnoDB в данном контексте это очевидно, думаю.
Не очевидно, каких именно проверок ссылочной целостности не хватает в Мускуле для полного счастья?
Можно чуть подробнее, что именно делает ваш демон?
Если речь идёт о CHECK, то это проверка не ссылочной целостности, а данных. При желании отлично решается через триггеры.
Всё остальное (not null, unique, foreign keys) реализовано в MySQL в рамках стандарта SQL-92.
Вы это серьёзно?
ЗЫ. Тому кто не понял вопрос и влепил минус отдельное спасибо.
Можно об этом чуть подробнее?
4. Да, согласен про палец :) Задал вопрос, смотря на тему со своей колокольни. Среднюю температуру по больнице понял, спасибо!