А подскажите вот еще какой вопрос. Я написал модуль, в котором переопределил метод .downcase класса String. Но не при include, ни при extend он не вызывается — вызывается стандартный метод объекта String. Исходя из описания, это должно работать при extend, но увы — что-то я не так понял. То есть интересует следующее
module M1
def downcase
return 'Hello!'
end
end
class String
include M1
end
'Привет'.downcase
=> «Привет»
У меня независимо от использования include и extend — всегда возвращается 'Привет'. Как правильно переопределять существующие методы?
Тоже сначала так думал. А потом решил — зачем лишнее звено? Данные в моем проекте проходят несколько последовательных массовых обработок, и храня промежуточные значения в ElasticSearch все равно получил значительный прирост в скорости. Вот и подумал — рискну, сделаю без PG вовсе.
В принципе, на 50-150 мс я выходил (о чем и пишу выше). Проблемы были именно при первом обращении к данным. После кеширования индекса все было замечательно.
Так и было. Сначала был вариант Postgress + файловая система. То есть тупо агрегированные данные записывались в определенную систему папок в сгруппированном виде. И раз в месяц стирались. Кстати, до сих пор считаю этот вариант самым предсказуемым по скорости при первом доступе к данным.
Потом Postgres + Redis. В этом случае все почти здорово, но если диск безразмерен, то память конечна, и это несколько напрягало. На диск я могу данные класть хоть по крону (так сказать, предподготовка кеша раз в неделю). Но отдавать под Редис пару десятков гигов смысла нет. Е раз нет — проблема прогрева все равно остается.
ElasticSearch эту проблему решил. Сейчас этот вариант — основной. Конечно, есть опасения в стабильности решения, доверия PostgreSQL больше (старый конь борозды не портит), но с другой стороны — выгоды от применения просто неожиданно полно перекрыли бизнес-требования, что решили рискнуть.
Очень интересная статья, спасибо. Хотя у меня случай обратный. Так и не удалось сделать на Postgress систему из 30 млн. записей с высокой доступностью данных. То есть система имела характер, когда примерно 5% записей использовались регулярно, а остальное очень редко. В итоге, при обращении к редким записям начинался процесс подгрузки данных с диска, который занимал до 30 секунд. Повторная выборка занимала уже 5 секунд, третья — 150-300 мс. Но до третьей уже редко кто доходил. Потом мог быть перерыв неделю, за которую эти данные «вымывались» из памяти, и все повторялось сначала.
В итоге отползли полностью на ElasticSearch. Там в худшем случае прогрев занимает 3-5 секунд. Побочная плюшка — на прогретых данных мы забыли что такое «сотни миллисекунд» и оперируем только десятками милисекунд.
В итоге постгресс используется в основном только для хранения логов и аналитики, поскольку SQL-запрос конечно написать проще, чем JSON-запрос. :)
Хм. Забавно. Не знал. Наличие схем как раз и стало основной причиной моего ухода в PostgreSQL. Но видимо есть какие-то нюансы.
Мне не удалось сейчас найти достаточно информации о схемах в MySQL, по крайней мере чтобы понять их отличие от понятия database. В «мире» PostgreSQL информации много и очень «тонкой» и детальной. То есть в любом случае, в PG схемы гораздо боле распространены.
Насколько я понял, в MySQL — схема просто синоним database. Но что это такое и чем это отличается от database — непонятно
Для PostgreSQL в Интернете куча описаний, как написать ActiveRecord применительно к схемам Postgres. Но нет описания, как применить схемы MySQL в ActiveRecord.
Видимо, есть все же какие-то различия, и предположу, что существенные. Был бы рад почитать мнение того, кто детально разбирался с тем и другим.
In mysql a database is a schema. The two words can be used interchangeably in most commands. For instance, you could say create database dbname, or create schema dbname and achieve the same result.
Postgres has a different concept of schema. It is a namespace that contains tables, functions, operators and data types. It is essentially a layer between the database and the tables. In postgres, a database may contain many schemas and those schemas may contain the same tables or different ones. The «public» schema is the default schema in a database.
database — это объек, изолированный от других database. А схема позволяет им взаимодействовать. Например, если есть таблицы вида
billing
— daily
— weekly
— monthly
users
— users
то в postgress можно сделать так (примерный запрос — возможно с ошбками):
SELECT uu.user_id, bd.bill FROM users.users uu
JOIN billing.daily bd ON bd.user_id=uu.user_id
WHERE user_id=777;
То есть однотипные таблицы, как в папке четко структурированы в схеме. Это значительно облегчает восприятие кода и проектирование СУБД. В теории это можно повторить префикасми в именах таблиц MySQL, но теряется красота инженерной мысли. :)
Ну и плюс доступы можно по разному на группы таблиц ставить. Например, для отдельного девелопера дать доступ в users.*, но закрыть в biling.*
Очень интересно из отсутствующего в Вашем списке — схемы! Это отличный вариант изолировать для различных модулей ПО и структурировать таблицы базы данных, при этом оставив возможность обращаться и комбинировать таблицы разных схем.
У меня падал. Однажды была история, когда раз в неделю MySQL стабильно писал corrupt и падал. При этом PostgreSQL на той же машине вел себя безупречно. Начали разбираться. Через неделю только в одном месте прочли, что возможно, виноват аппаратный RAID со встроенным кешем. Попробовали его отключить — и все заработало как надо. Это конечно не чистый ответ на Ваш вопрос. :) Но бяка происходила на коммерческом сервисе, так что «осадочек остался». :)
В целом — ощущение от PostgrSQL как от более «взрослой», серьезной системы.
Deadline должен быть — без сомнения. Но deadline бывает разный. Бывает — определенный подрядчиком, и принятый заказчиком. А бывает — навязанный заказчиком, который по ходу меняет ТЗ, который «играет» в политику с вышестоящим руководством. И тогда, в большей степени, именно deadline является проблемой — потому что именно он демотивирует команду, что раскручивает маховик рисков с еще большей силой.
Компаний такого масштаба, на примере которой я это написал — в стране немного, и все так работают. Увы, идти некуда. Или кардинально менять профиль работы и уходить в средний бизнес.
Действительно, слишком много «если». а по поводу адекватности заказчика, то здесь есть вот какое наблюдение.
1. Если (ох уж эти «если») мы говорим про стартап — то есть важный момент — заказчик и владелец — одно лицо, то понятие «работать на совесть» имеет место быть.
2. Но если компания чуть больше, и есть владелец, есть генеральный, а есть менеджер проекта (он же заказчик), то все становится интереснее.
а) менеджер проекта не заинтересован показывать свою некомпетентность перед генеральным. Если он видит, что ТЗ неполное, ему проще надавать на подрядчика-разработчика, чем признать, что что-то забыл, а если видит срыв по срокам, то он будет жестко давить на подрядчика с криками «твои проблемы», одновременно говоря генеральному — «да они у… не умеют работать, и срывают сроки».
б) Генеральный уже пообещал по пьяни или в бане акционеру: «Михалыч, ты че, меня не знаешь? Все организую, все будет четко и в срок — у меня же классная команда». Теперь ему легче депремировать менеджера проекта, наорать на него, и пообещать уволить. Разве может генеральный признаться владельцу, что он не умеет управлять процессом или нанимать тех людей, которые могут качественно управлять процессом.
в) Владелец… вот он как раз и заинтересован работать на совесть, и легко может сроки перенести, и о качестве подумать… но как к нему доберется подрядчик через фильтры а) и б)? :)
Да, точно. Мне удалось в одном проекте выступать со стороны бизнеса, в другом со стороны техники. Опыт — мощнейший. И я вынес похожие мысли.
Для бизнеса критически важен срок, поскольку к нему подгоняется реклама (планируется за пару месяцев), PR, проводятся обучения, нанимаются продажники. То есть запускается «мотор», и если в срок не поставят колеса — мотор будет безвозвратно жечь бензин, снижая прибыль. Хуже — вся команда запуска проекта и продаж постепенно деморализуется, и чем дальше уходят сроки, тем хуже (пассивнее) будет старт проекта.
При этом качество продукта вторично. В принципе, на уровне ТЗ все предусмотреть нельзя. Поэтому лучше стартовать, раньше начать зарабатывать деньги и заниматься уже улучшениями/тюнингом. Я сейчас даже этой стратегии в своих личных маленьких проектах придерживаюсь: сделать базис, стартовать, потом уже мелочи делать.
Для разработчика логика другая. Хочется сделать хорошо и правильно. Но в условиях сжатых сроков начинают применяться неоптимальные алгоритмы, и часто «прибитые гвоздями». Главное — быстрее сделать базис, который нормально должен работать.
А тут заказчик приходит с маркетологом, и начинают говорить: «а давай такую плюшку сделаем?». То, что еще базис не работает как надо, и эта плюшка — изменение ТЗ и ломка графика, это же заказчика не волнует?
Вот и получается, что следствием deadline является:
1. Некачественный продукт (при попустительстве заказчика)
2. Более-менее вылизанный базис продукта, но прибитый гвоздями
3. Кое-как прилепленные «на коленке» плюшки заказчика (часто вне бизнес-анализа и архитектуры)
4. Демотивация разработчиков (продукт плохой, невовремя, плюс еще «через коленку» заставляют плюшки лепить.
Но… без deadline нельзя, см. начало моего сообщения. :)
В одном рекламном блоке (по одному дому) идет сразу два адреса:
Продается 1 комна…
Московская область, Пушкино, Пушкина, 8
1 комната…
Продаю 1 комнатную квартиру в Пушкинском р-не п. Лесной, Пушкина, д.8
То есть тоже вот пример — п. Лесной — в черте города, и его просто опускают при вводе.
По поводу n-gramm — все же не соглашусь. Они не исправляют ошибки эффективно, а при ранжировании результатов поиска могут серьезно ухудшить выборку. Например, в большинстве алгоритмов, если человек введет пушкин вместо пушкино — то по n-gramm пушкин будет доминировать.
Или другой пример — Саратов. Если ошибиться и написать Сартов — то n-gramm найдет поселок (или село — не помню точно) Сартово — оно более релевантно этой ошибке.
Вообще, в целом, я более-менее приемлимый результат получил только проводя последовательно несколько проверок:
— точное совпадение начала типа объекта (г, р-н, обл)
— точное совпадение по каждому значащему слову
— совпадение по граничному n-gramm с правом одной ошибки
— совпадение по n-gramm с правом одной ошибки
Вот только при этом получается что-то приемлимое. что-то вроде такого
module M1
def downcase
return 'Hello!'
end
end
class String
include M1
end
'Привет'.downcase
=> «Привет»
У меня независимо от использования include и extend — всегда возвращается 'Привет'. Как правильно переопределять существующие методы?
Потом Postgres + Redis. В этом случае все почти здорово, но если диск безразмерен, то память конечна, и это несколько напрягало. На диск я могу данные класть хоть по крону (так сказать, предподготовка кеша раз в неделю). Но отдавать под Редис пару десятков гигов смысла нет. Е раз нет — проблема прогрева все равно остается.
ElasticSearch эту проблему решил. Сейчас этот вариант — основной. Конечно, есть опасения в стабильности решения, доверия PostgreSQL больше (старый конь борозды не портит), но с другой стороны — выгоды от применения просто неожиданно полно перекрыли бизнес-требования, что решили рискнуть.
В итоге отползли полностью на ElasticSearch. Там в худшем случае прогрев занимает 3-5 секунд. Побочная плюшка — на прогретых данных мы забыли что такое «сотни миллисекунд» и оперируем только десятками милисекунд.
В итоге постгресс используется в основном только для хранения логов и аналитики, поскольку SQL-запрос конечно написать проще, чем JSON-запрос. :)
Видимо, есть все же какие-то различия, и предположу, что существенные. Был бы рад почитать мнение того, кто детально разбирался с тем и другим.
Наиболее вменяемое, но ничего не объясняющее толком объяснение я нашел вот тут: www.estelnetcomputing.com/index.php?/archives/10-Database-vs.-Schema-Definition-in-Mysql-vs.-Postgres.html
In mysql a database is a schema. The two words can be used interchangeably in most commands. For instance, you could say create database dbname, or create schema dbname and achieve the same result.
Postgres has a different concept of schema. It is a namespace that contains tables, functions, operators and data types. It is essentially a layer between the database and the tables. In postgres, a database may contain many schemas and those schemas may contain the same tables or different ones. The «public» schema is the default schema in a database.
billing
— daily
— weekly
— monthly
users
— users
то в postgress можно сделать так (примерный запрос — возможно с ошбками):
SELECT uu.user_id, bd.bill FROM users.users uu
JOIN billing.daily bd ON bd.user_id=uu.user_id
WHERE user_id=777;
То есть однотипные таблицы, как в папке четко структурированы в схеме. Это значительно облегчает восприятие кода и проектирование СУБД. В теории это можно повторить префикасми в именах таблиц MySQL, но теряется красота инженерной мысли. :)
Ну и плюс доступы можно по разному на группы таблиц ставить. Например, для отдельного девелопера дать доступ в users.*, но закрыть в biling.*
В целом — ощущение от PostgrSQL как от более «взрослой», серьезной системы.
1. Если (ох уж эти «если») мы говорим про стартап — то есть важный момент — заказчик и владелец — одно лицо, то понятие «работать на совесть» имеет место быть.
2. Но если компания чуть больше, и есть владелец, есть генеральный, а есть менеджер проекта (он же заказчик), то все становится интереснее.
а) менеджер проекта не заинтересован показывать свою некомпетентность перед генеральным. Если он видит, что ТЗ неполное, ему проще надавать на подрядчика-разработчика, чем признать, что что-то забыл, а если видит срыв по срокам, то он будет жестко давить на подрядчика с криками «твои проблемы», одновременно говоря генеральному — «да они у… не умеют работать, и срывают сроки».
б) Генеральный уже пообещал по пьяни или в бане акционеру: «Михалыч, ты че, меня не знаешь? Все организую, все будет четко и в срок — у меня же классная команда». Теперь ему легче депремировать менеджера проекта, наорать на него, и пообещать уволить. Разве может генеральный признаться владельцу, что он не умеет управлять процессом или нанимать тех людей, которые могут качественно управлять процессом.
в) Владелец… вот он как раз и заинтересован работать на совесть, и легко может сроки перенести, и о качестве подумать… но как к нему доберется подрядчик через фильтры а) и б)? :)
Для бизнеса критически важен срок, поскольку к нему подгоняется реклама (планируется за пару месяцев), PR, проводятся обучения, нанимаются продажники. То есть запускается «мотор», и если в срок не поставят колеса — мотор будет безвозвратно жечь бензин, снижая прибыль. Хуже — вся команда запуска проекта и продаж постепенно деморализуется, и чем дальше уходят сроки, тем хуже (пассивнее) будет старт проекта.
При этом качество продукта вторично. В принципе, на уровне ТЗ все предусмотреть нельзя. Поэтому лучше стартовать, раньше начать зарабатывать деньги и заниматься уже улучшениями/тюнингом. Я сейчас даже этой стратегии в своих личных маленьких проектах придерживаюсь: сделать базис, стартовать, потом уже мелочи делать.
Для разработчика логика другая. Хочется сделать хорошо и правильно. Но в условиях сжатых сроков начинают применяться неоптимальные алгоритмы, и часто «прибитые гвоздями». Главное — быстрее сделать базис, который нормально должен работать.
А тут заказчик приходит с маркетологом, и начинают говорить: «а давай такую плюшку сделаем?». То, что еще базис не работает как надо, и эта плюшка — изменение ТЗ и ломка графика, это же заказчика не волнует?
Вот и получается, что следствием deadline является:
1. Некачественный продукт (при попустительстве заказчика)
2. Более-менее вылизанный базис продукта, но прибитый гвоздями
3. Кое-как прилепленные «на коленке» плюшки заказчика (часто вне бизнес-анализа и архитектуры)
4. Демотивация разработчиков (продукт плохой, невовремя, плюс еще «через коленку» заставляют плюшки лепить.
Но… без deadline нельзя, см. начало моего сообщения. :)
Пат!
В одном рекламном блоке (по одному дому) идет сразу два адреса:
Продается 1 комна…
Московская область, Пушкино, Пушкина, 8
1 комната…
Продаю 1 комнатную квартиру в Пушкинском р-не п. Лесной, Пушкина, д.8
То есть тоже вот пример — п. Лесной — в черте города, и его просто опускают при вводе.
По поводу n-gramm — все же не соглашусь. Они не исправляют ошибки эффективно, а при ранжировании результатов поиска могут серьезно ухудшить выборку. Например, в большинстве алгоритмов, если человек введет пушкин вместо пушкино — то по n-gramm пушкин будет доминировать.
Или другой пример — Саратов. Если ошибиться и написать Сартов — то n-gramm найдет поселок (или село — не помню точно) Сартово — оно более релевантно этой ошибке.
Вообще, в целом, я более-менее приемлимый результат получил только проводя последовательно несколько проверок:
— точное совпадение начала типа объекта (г, р-н, обл)
— точное совпадение по каждому значащему слову
— совпадение по граничному n-gramm с правом одной ошибки
— совпадение по n-gramm с правом одной ошибки
Вот только при этом получается что-то приемлимое. что-то вроде такого
— + 0.0000 init_parser Исходная строка: 'Спб, Марш. Жукова, 44 128'
+ 0.0003 clean_addr Очистка строки: 'спб, марш. жукова, 44 128'
+ 0.0003 split_addr Разбиение строки: [«спб», «марш.», «жукова», «44», «128»]
+ 0.0007 detect_sections Найдены секции: маршрут: [«спб», «марш.», «жукова»] дом: [«44», «128»], неизвестно: []
+ 0.0007 normalize_secti Финальные секции: маршрут: [«спб», «марш», «жукова»] дом: [«44», «128»], неизвестно: []
+ 0.0008 normalize_house Параметры house: [«44 (house)», «128 (kvartira)»]
+ 0.0008 replace_synonym Замена синонимов: [«санкт-петербург», «марш», «жукова»]
+ 0.0015 parse_federals Город федерального значения: [спб] -> [санкт-петербург] (исправлена ошибка написания)
+ 0.0015 parse_region Регион не найден
+ 0.0016 parse_area Район не найден
+ 0.0017 detect_route_el [«санкт-петербург (city)», «марш (street)», «жукова (street)»]
+ 0.0175 search_route Найдено 1 возможных варианта(ов)
+ 0.0179 profile_route Найден адрес 'г. Санкт-Петербург / проспект Маршала Жукова' (score=1.0)
+ 0.0180 parse_house Подготовлен запрос: '[«дом 44»]'
+ 0.0180 parse_house Формат квартиры — long: 'дом 44 квартира 128', short: 'д.44 кв.128'
+ 0.0347 validate_house Постройка найдена: 'дом 44 квартира 128'
198262, Город Санкт-Петербург, Проспект Маршала Жукова, дом 44 квартира 128
:)