Comments 189
Если UPDATE-запрос на таблице приводит к пересчету индекса, то ни один использующий этот индекс SELECT до окончания пересчета (ну или во время переключения, если вы верите в ровные руки авторов своей СУБД) выполнится, увы. В PostgreSQL при использовании immutable tuples любой UPDATE приводит к пересчету всех индексов таблицы.
Непонятно, что вы имеете в виду. Что такое «пересчет» индекса? UPDATE, конечно же апдейтит индекс, но это вполне уживается с SELECT'ом.
The core PostgreSQL system obtains AccessShareLock on the index during an index scan, and RowExclusiveLock when updating the index (including plain VACUUM). Since these lock types do not conflict, the access method is responsible for handling any fine-grained locking it might need. An exclusive lock on the index as a whole will be taken only during index creation, destruction, or REINDEX.
https://www.postgresql.org/docs/9.6/static/index-locking.html
Если под «пересчетом» вы понимаете REINDEX, то нет, конечно же при UPDATE никакой REINDEX не делается.
Под пересчетом индекса я подразумеваю ситуацию, в которой большое количество SELECT запросов при встрече с большим количеством UPDATE-запросов создают затык. Если вы расскажете как этого затыка избежать — вы мне окупите все усилия на написание этой статьи.
Насколько я понимаю обычно путь джедая к светлой стороне такой
1) Замена update -> insert & delete
2) Если первый пункт не помог, аккумулирование изменений в очереди/кэше и отложенный multi insert/ multi update
3) Если же объем модифицирующих запросов на столько велик, что ничего не помогло, надо уходить с MySQL. Здесь сложно что то посоветовать куда уходить. Для примера можно посмотреть Cassandra, Click House итд
INSERT не приводит к пересчету индексов? То есть поток INSERT на таблицу не замедлит поток SELECT?
И перед сменой основной СУБД я бы все-таки попытался выжать поболе из используемой. А то все технологии со своими минусами, а с минусами этой мы вроде хоть знакомы.
И перед сменой основной СУБД я бы все-таки попытался выжать поболе из используемой. А то все технологии со своими минусами, а с минусами этой мы вроде хоть знакомы.
У INSERT… DELETE vs UPDATE откуда преимущества вообще? Кроме меньшего количества самих запросов. Uber по-моему свалила с PostgreSQL из-за иммутабельности tuples и вытекающих из этого проблем с оверпересчетом индексов при апдейтах даже непроиндексированных полей. И зашкаливания объемов бинарного лога, что увеличивает стоимость синхронизации серверов в кластере.
Сейчас погуглил, не нашел подтверждению пункту 1, так что можно его считать не актуальным. Если не хочется возиться с новой технологией можно рассмотреть вариант репликации master/slave. Пишем в master читаем со slave. Правда при большом объеме модификаций возможно отставание реплик. В 5.7 появился cluster https://dev.mysql.com/doc/refman/5.7/en/faqs-mysql-cluster.html
и вытекающих из этого проблем с оверпересчетом индексов при апдейтах даже непроиндексированных полей.
Это не так. По неизвестной причине уберовцы написали просто вызывающе неверную информацию в своей статье и она, к сожалению, пошла в народ. При апдейте непроиндексированных полей срабатывает HOT-оптимизация и индекс не трогает ( с 2007 года так). Вообще в той статье убера, наряду с несколькими действительно разумными аргументами, есть несколько просто WTF-points.
any proof? я читал об этом не у них.
sure.
https://wiki.postgresql.org/wiki/Index-only_scans#Interaction_with_HOT
Ну и собственно, все что угодно по запросу «hot-optimisation postgres», это же не какой-то секрет
HOT (Heap-only tuples) is a major performance feature that was added in Postgres 8.3. This allowed UPDATES to rows (which, owing to Postgres's MVCC architecture, are implemented with a deletion and insertion of physical tuples) to only have to create a new physical heap tuple when inserting, and not a new index tuple, if and only if the update did not affect indexed columns.
https://wiki.postgresql.org/wiki/Index-only_scans#Interaction_with_HOT
Ну и собственно, все что угодно по запросу «hot-optimisation postgres», это же не какой-то секрет
Спасибо! делаю UPDATE.
А по умолчанию опция выключена? Или они там в Uber совсем тормозят?
А по умолчанию опция выключена? Или они там в Uber совсем тормозят?
По умолчанию включено, но оптимизация срабатывает тогда, когда новая строка находится на той же странице, что и старая ( помним, что при апдейте создается новая строка, так как они иммутабельны ) и возможно для повышения вероятности срабатывания нужно пошевелить параметр fillfactor ( подробнее здесь)
В случае убера мы можем попытаться предположить, что у них там большое количество индексов на таблице и большинство апдейтов все-таки затрагивают проиндексированные колонки, но это догадки.
В случае убера мы можем попытаться предположить, что у них там большое количество индексов на таблице и большинство апдейтов все-таки затрагивают проиндексированные колонки, но это догадки.
помогает?
я правильно понял что Uber уехали с PostgreSQL из-за проблем с пересчетом индексов? не разобрались как настроить? Такая очевидная справка?
или системные проблемы с пониманием СУБД?
я правильно понял что Uber уехали с PostgreSQL из-за проблем с пересчетом индексов? не разобрались как настроить? Такая очевидная справка?
или системные проблемы с пониманием СУБД?
помогает?
Безусловно.
В убере, по-моему, отдел БД просто любит движуху, вот и мигрируют туда-сюда. Не удивлюсь, если завтра они начнут переезжать куда-нибудь на VoltDB.
https://softwareengineeringdaily.com/2016/09/08/relational-databases-with-craig-kerstiens/
в этом подкасте упоминается что переход убера(и вброс статьи) был не только из-за технических вопросов, но и из-за вопроса кадров.
в этом подкасте упоминается что переход убера(и вброс статьи) был не только из-за технических вопросов, но и из-за вопроса кадров.
преимущество в том, что ненадо делать поиск по всей таблице. Это огромное преимущество
Скорее всего ситуация, когда большое количество SELECT запросов встречается с большим количеством UPDATE-запросов в одной и той же таблице — архитектурный просчет на этапе проектирования конкретной БД.
Нужен практический пример, когда вы столкнулись с такой ситуацией в реальной жизни.
Скорее всего можно предложить другую архитектуру хранения и использования данных для такого случая.
Нужен практический пример, когда вы столкнулись с такой ситуацией в реальной жизни.
Скорее всего можно предложить другую архитектуру хранения и использования данных для такого случая.
Вы уверены что это именно ошибка? Есть конкретные примеры решения такой архитектурной ошибки? Ну кроме уже предложенного выше способа «пишем в мастер, читаем со слейва».
Я ни в чем не уверен, до тех пор пока не понимаю сути конкретной, а не абстрактной проблемы — и я об этом написал. Сначала дайте конкретный практический случай этой проблемы (именно это я предложил выше), а уже потом спрашивайте какие есть варианты ее решения!
Площадка-интернет-магазин с редактированием товаров продавцами онлайн. Как архитектурно верно избежать встречного потока SELECT — UPDATE и связанного с встречей замедления обоих потоков?
Вделать журнал обновлений, а не модифицировать саму строчку
Какие фреймворки поддерживают прозрачную работу с данными в базе и еще находящимися в журнале? Потому что если такой поддержки нет, все бонусы от использования этого фреймворка нивелируются и начинается тотальный изврат.
INSERT в журнал обновлений встречается с SELECT по тому же журналу.
Стоимость развязки SELECT — INSERT чуть выше, чем SELECT — UPDATE, не согласны?
Стоимость развязки SELECT — INSERT чуть выше, чем SELECT — UPDATE, не согласны?
Insert происходит в другую таблицу, и в результате у нас селект не страдает
Как в такой схеме реализовать, к примеру, поиск товара по описанию, если описание — в журнале?
Так вроде же все очевидно — надо разделить потоки на две таблицы.
Выборка товаров для покупателей должна происходить из одной таблицы (user_table), а изменение-добавление продавцами в другой (main_table).
Периодически, по мере накопления изменений в main_table данные программно компилируются в один большой запрос типа:
для синхронизации таблиц main_table и user_table.
Выборка товаров для покупателей должна происходить из одной таблицы (user_table), а изменение-добавление продавцами в другой (main_table).
Периодически, по мере накопления изменений в main_table данные программно компилируются в один большой запрос типа:
INSERT INTO user_table (key_field, field_1, field_2, ...)
VALUES (key1 , ...), (key2, ...), (key3, ...), ...
ON DUPLICATE KEY UPDATE
field_1 = VALUES (field_1), field_2 = VALUES (field_2), ...
для синхронизации таблиц main_table и user_table.
На всякий случай добавлю — подразумевается конечно, что в запрос синхронизации попадут только данные последних изменений в товарах требующих синхронизации, а не вся таблица полностью. И как уже писали выше, небольшой лаг между внесением изменений и их появлением на фронте — для интернет магазина совершенно не критичен.
просто bunch?
теперь UPDATE-запросы идут не поодиночке, а предварительно группируются в «журнальной» main_table? и можно ли считать INSERT… ON DUPLICATE KEY UPDATE одним большим запросом?
теперь UPDATE-запросы идут не поодиночке, а предварительно группируются в «журнальной» main_table? и можно ли считать INSERT… ON DUPLICATE KEY UPDATE одним большим запросом?
просто bunch?Да
теперь UPDATE-запросы идут не поодиночке, а предварительно группируются в «журнальной» main_table?Да, но я не стал бы ее называть журнальной, скорее это основная таблица, а user_table — просто ее копия и желательно, чтобы она была вообще на другом сервере для изоляции буферов БД.
и можно ли считать INSERT… ON DUPLICATE KEY UPDATE одним большим запросом?Да. Особенно если запустить его в отдельной транзакции. Такой подход даст существенную экономию на операциях слива буферов изменений в сравнении с кучей отдельных запросов «однострочных» изменений.
Я правильно понимаю суть идеи — мы создаем вторую точку встречи на промежуточной таблице main_table и размазываем «нагрузку встречи» между двумя точками?
Суммарный оверхед от этого должен вырасти, но мы получаем механизм контроля над потоком UPDATE для изначальной точки — и даже можем попытаться коррелировать его с интенсивностью SELECT для той же таблицы.
Мне не очень нравится как скейлится такой подход — три точки встречи, четыре? — и поэтому как архитектурное решение он мне не нравится. Но вот в качестве экстренной аварийной меры может быть очень даже эффективным
Суммарный оверхед от этого должен вырасти, но мы получаем механизм контроля над потоком UPDATE для изначальной точки — и даже можем попытаться коррелировать его с интенсивностью SELECT для той же таблицы.
Мне не очень нравится как скейлится такой подход — три точки встречи, четыре? — и поэтому как архитектурное решение он мне не нравится. Но вот в качестве экстренной аварийной меры может быть очень даже эффективным
Кхм. Это практически стандартное решение, когда у нас множество апдейтов и селектов. Вы наверное не понимаете насколько insert дешевле update. insert просто вставляет запись, update же сначала ищет запись и т.п.
да-да-да, я вааще не понимаю чем INSERT… ON DUPLICATE KEY UPDATE… дешевле UPDATE. И в этой ветке обсуждается не журнальная таблица, а промежуточная.
А насчет дешевизны INSERT в контексте пересчета индексов уже отписывался
А насчет дешевизны INSERT в контексте пересчета индексов уже отписывался
Почему? Вполне обычное OLTP. Тут главное, чтобы SELECT и UPDATE были короткими.
Первая часть не учитывает, что довольно часто сайты пишутся на каких-то фреймворках, в которых заложены данные архитектурные проблемы и без костылей их не порешать.
Примеры?
Например, я работаю с odoo и там в основном кастомизация, с нуля никто не пишет.
Что бы, как вы написали, разбить таблички для продуктов, нужно перелопатить тысячи и тысячи кода.
Максимум, что помогает — денормализация)
Я бы назвал сильную связанность минусом yii2.
Dependency Injection — это паттерн, позволяющий легко подсовывать моки при юнит-тестах и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x. Иначе — атипаттерн.
Слабая связанность, гибкость и расширяемость, лучшая читаемость и переиспользуемость — это теперь зовется «атипаттерн»? SOLID, не?
Самый презираемый класс программистов — яваскриптовики
У Вас какие-то комплексы на этот счет? Так-то адекватные люди не разделяют коллег по языку программирования.
Я не понимаю как веб-разработчик вообще может на рабочей машине держать не линукс. Да, интерфейс ужасен, шрифты слетают, окна уродливы. Иксы — прекрасный пример отвратительной архитектуры. Да, приходится думать и/или гуглить там, где в винде и/или макоси достаточно жмакать кнопочки.
А какие-либо объективные плюсы линукса, как веб-разработчик, Вы можете назвать? Или только «мы ж и не дизайнеры»?
Я бы даже сказал, есть не очевидный плюс windows платформы. После всех набиваний шишек, в вашем git репозитории точно уже не будет:
— внезапных проблем с \r \n
— проблем с путями "\"
— проблем с путями, отличающихся лишь регистром
и даже больше, на ходу вспомнилось пока это
— внезапных проблем с \r \n
— проблем с путями "\"
— проблем с путями, отличающихся лишь регистром
и даже больше, на ходу вспомнилось пока это
Я бы отнес это к минусам, но холиварить отказываюсь, если что.
Какие-то двойные стандарты получаются на мой взгляд.
Вот вы ниже в ответ на
пишете
А тут получается если нужно задумываться про разные разделители путей, новой строки и регистрозависимость файловой системы — это минусы.
Вот вы ниже в ответ на
А какие-либо объективные плюсы линукса, как веб-разработчик, Вы можете назвать?
пишете
А линукс заставляет думать. И уметь.
А тут получается если нужно задумываться про разные разделители путей, новой строки и регистрозависимость файловой системы — это минусы.
разделители путей и тип новой строки — это такие смешные проблемы, что я, простите, о них уже и не вспомню. надеюсь, никогда.
посыл изначально был о том, что под линухами даже конечным пользователям приходится решать проблемы, достаточно сходные с деплоем web проекта, к примеру. как мимнимум тренирует навыки StackOverflow-driven-development.
посыл изначально был о том, что под линухами даже конечным пользователям приходится решать проблемы, достаточно сходные с деплоем web проекта, к примеру. как мимнимум тренирует навыки StackOverflow-driven-development.
Простите, но какие из этих проблем у вас возникали не под Windows?
Я вот с переходом на Windows испытываю проблемы:
1) С кодировкой (да да, шиндовс до сих пор держит зоопарк из UTF8, cp1251 и даже IBM866 на выдаче VC компилятора)
2) Со злополучными \r\n, в то время как другие ОС принимают любой из вариантов виндовс верен своим стандартам и без \r часто убирает переносы строк, в разном софте по разному, не угадаешь.
3) После шиндовспрограммистов приходится долго и муторно править регистры путей, а бэкслэши вместо слэшей у всех остальных ОС добавляют смеху, ведь CMake (и много других сборщиков и не только) и под шиндовсом принимает стандартный '/', а шиндовая консоль нет.
Итого: если у вас сервера на винде — могу вам только посочувствовать, а если на *nix, то вы огребёте проблем при деплое после разработки на винде. Где тут профит я не вижу.
Я вот с переходом на Windows испытываю проблемы:
1) С кодировкой (да да, шиндовс до сих пор держит зоопарк из UTF8, cp1251 и даже IBM866 на выдаче VC компилятора)
2) Со злополучными \r\n, в то время как другие ОС принимают любой из вариантов виндовс верен своим стандартам и без \r часто убирает переносы строк, в разном софте по разному, не угадаешь.
3) После шиндовспрограммистов приходится долго и муторно править регистры путей, а бэкслэши вместо слэшей у всех остальных ОС добавляют смеху, ведь CMake (и много других сборщиков и не только) и под шиндовсом принимает стандартный '/', а шиндовая консоль нет.
Итого: если у вас сервера на винде — могу вам только посочувствовать, а если на *nix, то вы огребёте проблем при деплое после разработки на винде. Где тут профит я не вижу.
В этом и плюс, после Windows у вас в проекте не будет таких проблем, когда будут приходить другие Windows программисты, т. к. вы сами эти проблемы и решите.
Ещё раз — проблемы будут на деплое. Или я должен следить за всеми? Или код под диктовку писать чтоб никто не косячил? Да и невозможность таких «ошибок» явно лучше их исправления.
Я вообще негативно отношусь к Windows и Windows программистам так как считаю, что хорошее ПО должно быть кроссплатформенно и для этого сейчас есть всё, что необходимо, а разрабатывать под виндой это как кактус есть хотябы потому, что консоль и кодировки.
Я вообще негативно отношусь к Windows и Windows программистам так как считаю, что хорошее ПО должно быть кроссплатформенно и для этого сейчас есть всё, что необходимо, а разрабатывать под виндой это как кактус есть хотябы потому, что консоль и кодировки.
Хуки на гите, отсутствия в проекте файлов вида *.lua и прочее — вот это всего не будет, потому что наличие windows разработчика означает что проект собирается и работает под windows.
Не очень понял чем работа в Windows мешает кроссплатформенности. Наоборот, если вся команда на linux, кто тогда делает порт на Windows?
Консоль… вы можете поставить любую консоль. Bash, powershell, etc
Как и окружение. Все прекрасно настраивается, кастомизируется. Заметьте, Linux из коробки тоже не огонь.
Не очень понял чем работа в Windows мешает кроссплатформенности. Наоборот, если вся команда на linux, кто тогда делает порт на Windows?
Консоль… вы можете поставить любую консоль. Bash, powershell, etc
Как и окружение. Все прекрасно настраивается, кастомизируется. Заметьте, Linux из коробки тоже не огонь.
К сожалению, наличие windows-разработчика на проекте чаще означает корявые коммиты в CVS и прочие проблемы, чем их отсутствие.
Ну то есть вы говорите «давайте будем снисходительны к программистам под виндой». Ну как бы ок, я понял. Вы даже вероятно правы по поводу того, что в кроссплатформенном ПО проблемы всё равно придётся решать.
Чтож, пусть каждый пишет где ему нравится, я как и прежде буду считать, что это АД.
А Linux из коробки (без GUI) для серверов норм.
Чтож, пусть каждый пишет где ему нравится, я как и прежде буду считать, что это АД.
А Linux из коробки (без GUI) для серверов норм.
Ну вот я снисходителен к Linux разработчиком, чьи проекты не запускаются на Windows из репозитория, хотя должны, т. к. используют кроссплатформенные инструменты. Логично ожидать подобного.
Лучше пинать обоих, может начнут писать нормально =)
Вообще смотря на чём, я сталкивался только с C++, так вот кто-то мне уже тут говорил, что если писать в соответствии со стандартом, то никаких проблем не будет, а платформозависимые функции стандартом не назовёшь, не говоря уже о неопределённом поведении.
Вообще смотря на чём, я сталкивался только с C++, так вот кто-то мне уже тут говорил, что если писать в соответствии со стандартом, то никаких проблем не будет, а платформозависимые функции стандартом не назовёшь, не говоря уже о неопределённом поведении.
да да, шиндовс до сих пор держит зоопарк из UTF8, cp1251 и даже IBM866
А вы хоть раз смотрели список кодировок, которые предлагаются некоторыми линуксовыми дистрибутивами при установке в качестве возможных системных? Если хоть выбрать любую из них, то потом в крокозяблы превращаются даже маны… Интересно, зачем вообще в настройки добавляют опцию, которая не работает? :-)
Что же до проблем с кодировкой на винде — то на самом деле проблема не в винде, а в американских разработчиках, которые эти кодировки игнорируют. Почему-то мои программы проблем с кодировками не испытывают.
Со злополучными \r\n, в то время как другие ОС принимают любой из вариантов виндовс верен своим стандартам и без \r часто убирает переносы строк, в разном софте по разному, не угадаешь.
Не путайте Windows и Notepad. Это немного разные программы.
ведь CMake (и много других сборщиков и не только) и под шиндовсом принимает стандартный '/', а шиндовая консоль нет
На самом деле понимает, только надо не забывать заключать пути в кавычки.
А вы хоть раз смотрели список кодировок, которые предлагаются некоторыми линуксовыми дистрибутивами при установке в качестве возможных системных?
Ниразу не видел, увы. В любом случае есть возможность «сделать хорошо», в винде такой возможности нет совсем.
Почему-то мои программы проблем с кодировками не испытывают.
Мне сложно говорить за всех, я тут в установщиках стабильно наблюдаю кракозябры. И повторюсь про VC компилятор, IBM866 ни в какие рамки, пришлось использовать английский, иначе не лечится.
Не путайте Windows и Notepad. Это немного разные программы.
Я вас, вероятно, огорчу, но разработчик один и Notepad входит в стандартную поставку без возможности выпилить. Да и были программы (за давностью лет не помню какие), которые делали то же самое.
На самом деле понимает, только надо не забывать заключать пути в кавычки.
К сожалению часто берутся относительные пути, а комбинации '\' и '/' винда не приветствует даже с кавычками. Во всяком случае у меня не вышло, но может руки неоттуда?
Вообще всё это холивар, который по факту не приведёт к моей любви к этой ОС или вашей ненависти. Вы либо работаете только с Windows, либо не программист, ну я не знаю других причин почему её можно любить.
На самом деле есть еще вариант кросс платформенного приложения под Win/OS X + веб сервисы. Разрабатывать под винду из под Wine то еще "удовольствие". Для комфортной разработки под OS X так или иначе желателен мак. Зато весь веб стек заводится с полпинка на Windows. Вопрос c консолью тоже закрывается очень легко. У меня скажем есть в консоли bash, все утилиты типа grep, awk и прочие. Сейчас вот появилась еще Windows Subsystem for Linux. Вопрос \n vs \r\n тоже закрывается прямо при установке git (checkout \r\n push \n). Раньше еще был плюс в виде Notepad++ — на глаз один из самых быстрых редакторов в плане открытия файла. С выходом VSCode это уже не так актуально.
Правда есть один нюанс. win10 ужасно не стабильная и тормозящая ось. А вот win7 была вполне себе ничего
Зато весь веб стек заводится с полпинка на Windows
Увы, я против веб. Не везде он применим и бэкэнд во многих случаях даже у веба далеко не js.
А если это был упрёк, что веб-стэк трудно завести где-то ещё, то вы снова сильно ошибаетесь, на windows его завести по моему опыту сложней всего в сравнении с другими ОС. И да, win10 невозможно пользоваться, я уже второй месяц в этом убеждаюсь.
Раньше еще был плюс в виде Notepad++
Плюс куда? Винде? Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе. А код в текстовом редакторе я бы даже не пытался писать.
У меня скажем есть в консоли bash, все утилиты типа grep, awk и прочие
Осталось добавить их в стандартную поставку, были проблемы с установкой дополнительного софта в одной организации.
Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе. А код в текстовом редакторе я бы даже не пытался писать.
Ну и в чем в таком случае проблема?
Вы это к чему написали? Проблемы описаны выше — наличие у Windows ряда исключительно собственных решений, которые приводят к конфликтам при разработке и не только. А IDE и редакторы тут вообще не при чём.
К тому, что вы вольны не использовать эти решения, если они приносят больше проблем, чем пользы.
Если вы используете JetBrains или Sublime — то наличие в винде кривого Notepad вашей проблемой не является.
А если это был упрёк, что веб-стэк трудно завести где-то ещё
Нет как раз наоборот. Веб стэк легко завести на чем угодно OS X/Win/Ubuntu/CentOS итд
Увы, я против веб. Не везде он применим и бэкэнд во многих случаях даже у веба далеко не js.
Я лично без проблем заводил под Win node.js, php/nginx, php/apache, golang, rust(правда на ранних версиях была проблема с openssl), java бэкенд. Мне кажется это покрывает процентов 80 всех вариантов
Плюс куда? Винде? Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе.
JetBrains тяжеловат, плюс к тому будучи написанным на java работает на любой оси. Sublime — да, неплох
Осталось добавить их в стандартную поставку, были проблемы с установкой дополнительного софта в одной организации.
мне кажется не сложнее установки нужных пакетов из aptitude, brew итд.
мне кажется не сложнее установки нужных пакетов из aptitude, brew итд.
Вы не в ту сторону подумали. Права, согласовать, заставить с этим работать всех разработчиков (когда ты один на Маке, целевая Android, но тестовый интерфейс на Qt должен работать на винде, ибо частично тебе с базой «помогает» Windows-программист). Не тривиальная задача настроить сборку в три платформы с минимумом доп утилит и одним методом, ещё и чтоб это работало у каждого в своей IDE.
По вашему комментарию (https://habrahabr.ru/post/329478/?reply_to=10241628#comment_10241608) понял о чем Вы говорите. Да с C++ есть проблемы в области кроссплатформенности. Есть какие то подвижки в правильном направлении (например при использовании CMake) к унификации, но в плане организации сборки, нормального кроссплатформенного решения я не нашел. Хотя мне кажется здесь проблема глубже. В С++ не хватает общего пакетного менеджера и нормального управления зависимостями. Может быть если бы приняли модули в 20 стандарте стало бы проще организовать сборку
а комбинации '\' и '/' винда не приветствует даже с кавычками
Ничего подобного, они работают в любых сочетаниях.
C:\Users\rucku>Xcopy /Y /E "../rucku/SDK.h" «F:/»
0 File(s) copied
C:\Users\rucku>dir
…
07.04.2017 13:34 204 709 SDK.h
…
C:\Users\rucku>Xcopy /Y /E "..\rucku\SDK.h" «F:\»
..\rucku\SDK.h
1 File(s) copied
Конечно, работает, только не везде видать.
Если Вас интересует именно вопрос копирования можно использовать http://gnuwin32.sourceforge.net/
c:\GnuWin32>cp ../GnuWin32/readme.txt ./var
c:\GnuWin32>cp ..\GnuWin32\readme.txt .\varОбе команды делают одно и то же
Есть еще cygwin, MinGW32 и WSL
Мы говорили про консоль Windows или как поставить линуксовый софт/виртуалку? Накатив кучу софта все могут, а вы попробуйте убедить пяток разработчиков, которым это всё до лампочки, что надо это ставить. Или пользуйтесь тем, что есть по умолчанию.
Я серьёзно сталкивался с этой проблемой и серьёзно решал её через родные средства (за исключением make/cmake).
Я серьёзно сталкивался с этой проблемой и серьёзно решал её через родные средства (за исключением make/cmake).
«У меня нет комплексов, я просто хочу делать это только с тобой» (с) «От 180 и выше».
А вообще-то имелась в виду ситуация, когда бекенд-разработчики презрительно относятся к фронтенд-разработке. Особенно это комично в случаях, когда последние получают больше.
По поводу Dependency Injection — покажите как вы его используете. И сколько программистов и пилят именно тот код, в котором используется DI?
А вообще-то имелась в виду ситуация, когда бекенд-разработчики презрительно относятся к фронтенд-разработке. Особенно это комично в случаях, когда последние получают больше.
По поводу Dependency Injection — покажите как вы его используете. И сколько программистов и пилят именно тот код, в котором используется DI?
Мы например используем одну доменную область для веба и для мобилок. Без ди это был бы угар, ад и содомия. А так у нас есть общая бизнес логика, которая подстраиваться под запускаемую платформу. И без ди очень трудно отслеживать общие объекты. Хотя может это и не так заметно в пхп, где все живет только с запросом.
+ очень удобно подцеплять, отцеплять декораторы и перехватчики
+ очень удобно подцеплять, отцеплять декораторы и перехватчики
А так у нас есть общая бизнес логика, которая подстраиваться под запускаемую платформу
это отсылает к аргументу phgrey —
и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x..
Если потратить на solid немного больше времени — начинаешь замечать, что часть принципов противоречит друг другу, и тянет архитектуру приложения в разные стороны. D тянет в слабую связанность, но на связность влияет скорее отрицательно. S повышает связность, но может негативно сказываться на связанность.
D+S+O дают много лишних интерфейсов, связанных с абстракцией реализации, а не абстракцией предметной области.
D+S+O+I легко нарушают kiss & yagni. Всё равно приходится идти на некоторые компромиссы.
А еще DI одинаково легко развязывает слои приложения и превращает код в di-лапшу из интерфейсов и реализаций, наследующих друг друга.
Зачем конфиг-то? Достаточно настраивать DI в Composition Root.
Конфиги это наследие прошлого, и тех кто везде хочет поздного связывания. Хотя это надо очень и очень маленькому функционалу и в редких случаях.
Я напримар использую автоконфигурирование, после явную регистрацию через код для сложный моментов. После идет конфигурация через конфиг файл, но мне это потребовалось всего один раз за всю карьеру(по сути это было больше для тестера, что бы он мог сравнивать несколько конфигураций кода, когда ему нужно было. когда было принято решение это улетело в автоконфигурацию)
Я напримар использую автоконфигурирование, после явную регистрацию через код для сложный моментов. После идет конфигурация через конфиг файл, но мне это потребовалось всего один раз за всю карьеру(по сути это было больше для тестера, что бы он мог сравнивать несколько конфигураций кода, когда ему нужно было. когда было принято решение это улетело в автоконфигурацию)
Безусловно каждый принцип можно довести до сумашествия. В этом и задача, что бы найти баланс и не проседать по любому из пунктов.
вы абсолютно правы, DI обретает дополнительные плюсы при использовании в долгоживущем приложении.
А линукс заставляет думать. И уметь.
Vagrant :)
И никаких проблем. Вообще. И шрифты в IDE приятные, да и в прочих программах тоже :) Ну да, нужно всего-лишь хотеть чуть чуть разобраться и может быть где-то потратить час на то что-бы исправить какую-то шероховатость один раз потому что разработчики оголтелые маководы и на линуксе у вас будет та же самая проблема :D
Серьёзно, оголтелые маководы последнее время становятся хоть и мелкой, но назойливой проблемой.
И никаких проблем. Вообще. И шрифты в IDE приятные, да и в прочих программах тоже :) Ну да, нужно всего-лишь хотеть чуть чуть разобраться и может быть где-то потратить час на то что-бы исправить какую-то шероховатость один раз потому что разработчики оголтелые маководы и на линуксе у вас будет та же самая проблема :D
Серьёзно, оголтелые маководы последнее время становятся хоть и мелкой, но назойливой проблемой.
Маководы — братья по unix. Я там kernel panic вот этим вот глазом видел. И GNU tools там в норме. И brew есть. И путь нормальный.
Если пользователь Windows разобрался с vagrant — то это наш человек, просто зачем-то насилующий себе разум.
Линуксоиды, по какой-либо причине юзающие иногда Окошечки — игры, фотожаба, мультимедиа, ie — не в счет.
Если пользователь Windows разобрался с vagrant — то это наш человек, просто зачем-то насилующий себе разум.
Линуксоиды, по какой-либо причине юзающие иногда Окошечки — игры, фотожаба, мультимедиа, ie — не в счет.
Пришлось однажды «братьям по UNIX» передавать пинок в Slack с подписью
git config --system core.ignorecase false
не совсем понял проблему:
OneTwoABBASD — рандом или цикл, не? к /tmp не приучены?
или OneTwoCamelCase в именах файлов напрягает?
OneTwoABBASD — рандом или цикл, не? к /tmp не приучены?
или OneTwoCamelCase в именах файлов напрягает?
Я если че и сам_snake_case_предпочитаю. Но с psr дружу без нервов.
Вот бы винда наконец-то на ядро линуха перешла.
по поводу «разобраться» — согласен на 300 процентов. Просто к некоторым проблемам привыкаешь и однажды при dist-upgrade просто лень гуглить.
Docker же :)
UFO just landed and posted this here
UFO just landed and posted this here
ага. глупцам и наглецам тут грустно
UFO just landed and posted this here
Установка серверного софта — одна команда в консоли, правка пары конфигов (обычно разработчику даже не нужна) и ещё команда на перезапуск сервисов. Если понадобится что-то специфичное — можно в процессе установки инструкцию админу писать, благо на сервере тот же линукс. Браузеры — лис и хромиум, никаких виртуалок под них не надо. IDE нынче кроссплатформенные; psd открывается gimp'ом, для вёрстки этого вполне хватает, если очень нужен именно фотошоп — под вайном он работает; что за «куча утилит, большая часть которых на линуксе не работает» — ума не приложу. А ещё рабочее место выходит дешевле, поскольку не нужно покупать лицензию на винду.
Лучше обоснуйте свой тезис про потраченное время, я как-то не замечаю чтоб из-за выбора оси я тратил по четыре лишних часа в день.
Лучше обоснуйте свой тезис про потраченное время, я как-то не замечаю чтоб из-за выбора оси я тратил по четыре лишних часа в день.
UFO just landed and posted this here
frontend в ветке не упоминался. только в вашем профиле
Везде вижу «веб-разработчиков», и не вижу «фронтенд».
Вы это про какой?
Линукс заставляет тратить много времени. И это дорого. Очень дорого.
Так стек же весь с пол оборота заводится, например docker-compose проект расшарил в команду и у всех одинаковое окружение, все инструменты нативные и работают как надо, костыли никакие не надо. На windows 10 помню пытался настроить окружение для разработки, но там постоянно что-то приходилось подпирать костылями, потому как все работало не совсем так. WSL конечно сглаживает эту проблему, но не до конца.
Repository + Entity — driven db access в 100% наблюдаемых мною случаев превращается в непригодный к дальнейшему использованию legacy код.
Если репозиторий не нагружать лишними функциями, то вполне себе рабочий вариант. Репозиторий должен кэшировать результаты и выполнять запросы в базу. Все остальное лишнее. Мне кажется куда более часто встречающаяся проблема это увлечение god object и не умение найти баланс в делении кода на атомарные логические сущности
Скорее всего причиной можно считать то, что репозитории используются в stateless режиме — как группа функций схожего назначения. В отличии от конкуриющего с ним паттерна ActiveRecord, в котором сразу ясно что именно является состоянием.
При активной работе над кодом нескольких программистов зачастую приходится специально договариваться по вопросу какие функции считать лишними, а какие — нет. В AR действительно получается проще договориться что к чему относить.
UFO just landed and posted this here
это чек-лист тащемта
UFO just landed and posted this here
тут еще один зануда проходил, говорил что правильно — чек-лист.
ну вот же — 1, 2, 3, 4 — списки проблем которые нужно проверить. с пояснениями.
тащемта в основном используется в смысле «вообще-то». И вы так спрашиваете, как будто это что-то плохое.
ну вот же — 1, 2, 3, 4 — списки проблем которые нужно проверить. с пояснениями.
тащемта в основном используется в смысле «вообще-то». И вы так спрашиваете, как будто это что-то плохое.
UFO just landed and posted this here
это не албанский, а прикольная опечатка. оказывается, ее можно использовать для выявления холиварщиков.
что делать? внимательно перечитать комментарии и искать специалиста. я могу двух показать. договариваться об удаленном аудите за сколько скажут.
не можете? обнять коленки и плакать.
что делать? внимательно перечитать комментарии и искать специалиста. я могу двух показать. договариваться об удаленном аудите за сколько скажут.
не можете? обнять коленки и плакать.
UFO just landed and posted this here
если не холиварить — у специалистов можно учиться. гуглить что там тебе советуют. смотреть, пробовать. понимать. даже спрашивать.
это мне чек-лист если что.
это мне чек-лист если что.
что делать неспециалисту? учиться задавать вопросы на английском языке.
в 99% случаев правильно поставленный вопрос получает ответ на гугле. Это называется StackOverflow driven development. Оставшийся один процент придется задать.
ну и правило «зачем?»: если ты не понимаешь зачем это — оно тебе не нужно.
в 99% случаев правильно поставленный вопрос получает ответ на гугле. Это называется StackOverflow driven development. Оставшийся один процент придется задать.
ну и правило «зачем?»: если ты не понимаешь зачем это — оно тебе не нужно.
Спасибо за статью. Такие замечания обычно предлагаются в личке, однако я бы хотел оставить его публично, в надежде чтобы его увидело большее количество людей, ничуть не пытаясь задеть чувства автора и прохожих (а вдруг).
Если можно, заголовок бы подправить: «чек-лист» пишется через тире. Это составное слово, такое, как всем известное со школы «диван-кровать», они всегда пишутся через тире, ибо правило гласит:
Замечаю просто сейчас в последнее время какую-то нездоровую тенденцию к их употреблению исключительно в таком виде, что, если честно, реально вымораживает. Ладно бы если изначально они писались бы верно, то тенденция пошла бы правильная, как это часто бывает, однако кому-то стоило начать писать не верно, с тех времен и клонируется… Заранее благодарен!
Если можно, заголовок бы подправить: «чек-лист» пишется через тире. Это составное слово, такое, как всем известное со школы «диван-кровать», они всегда пишутся через тире, ибо правило гласит:
Сложные существительные, образованные без соединительной гласной, каждая часть которых может употребляться как самостоятельное слово, пишутся через дефис.
Замечаю просто сейчас в последнее время какую-то нездоровую тенденцию к их употреблению исключительно в таком виде, что, если честно, реально вымораживает. Ладно бы если изначально они писались бы верно, то тенденция пошла бы правильная, как это часто бывает, однако кому-то стоило начать писать не верно, с тех времен и клонируется… Заранее благодарен!
Разве «чеклист» — не заимствованное из английского слово «checklist»?
В русском с этими дефисами в заимствованных словах что-то странное.
Вот взять хотя бы «дедлайн» вполне можно употреблять отдельные части самостоятельно.
Но дефис не пишут.
В русском с этими дефисами в заимствованных словах что-то странное.
Вот взять хотя бы «дедлайн» вполне можно употреблять отдельные части самостоятельно.
Но дефис не пишут.
В правилах увидел и другой пункт, касающийся уже непосредственно заимствованных слов, который точно в кассу: «сложные существительные с иноязычными элементами», но время редактирования коммента уже истекло к тому времени.
А насчет дедлайна — да, согласен, так уж завелось, так все и пишут. Но в любом случае, никак не раздельно)
А насчет дедлайна — да, согласен, так уж завелось, так все и пишут. Но в любом случае, никак не раздельно)
они всегда пишутся через тире, ибо правило гласит: "… пишутся через дефис"
Что-то я не понимаю...
Repository + Entity — driven db access в 100% наблюдаемых мною случаев превращается в непригодный к дальнейшему использованию legacy код.Автор, можете аргументировать более развернуто? Согласен с предыдущим комментарием: если не пихать в репо все подряд методы, код получается вполне чистым.
Запрос к 10 таблицам в вебе в продакшне может служить поводом для увольнения его автора и ревьювера, ИМХО. Господа, юнион, джоины и подзапросы 3-го уровня вложенности — это неплохой способ повыпендриваться.
Не очень понял альтернативу. Вот есть данные, лежат в 10 таблицах, надо их всех показать.
Вместо запроса к 10 таблицам делать 10 запросов?
да. хотите сравнительные результаты нагрузочного тестирования?
А можно какие то пруфы данного утверждения? Просто если с подзапросами я согласен, то join при правильном проектировании БД обычно проблем не вызывает. Обычно на мускуле самая большая проблема group by. Уже на 20млн записей посчитать статистику становится проблемой
Простите, я правильно понимаю, что вы предлагаете вытащить данные из 10 таблиц, передать их по сети, реализовать через сторонние библиотеки на другом сервере хеш соединение в памяти… и утверждаете, что это быстрее, чем нативная реализация СУБД? Я пользуюсь PG и могу точно сказать, что соединения в базе быстрее. И слабо верю, что в MySQL оно работает сильно хуже
Абсолютно правильно понимаете. Более того — я уже наблюдал результат такой оптимизации. Дважды. Про постгрес верю, но хочу спросить — на каких объемах данных и нагрузках?
Не сразу понял про соединение.
Не сразу понял про соединение.
Даное утверждение бред. Движки БД заточены на join. У mysql были проблеми с подзапросами (спигнул с него в достаточно давно на более взрослие БД. Поетому не скажу на сегодня, надеюсь исправили. Но и ето легко решалось временними таблицами). Но если правильно написать запрос и план будет логичним — никакой внешний движок не получит прироста при прочих равных условиях.
Положительний результат можно било получить только в условиях полного «топорного» использования БД.
Положительний результат можно било получить только в условиях полного «топорного» использования БД.
Могу сказать, что у меня идут запросы с агрегациями по соединениям таблиц, в каждой из которых около миллиона записей. Соединяются от трех до пяти таких таблиц. Соединение идёт по покрывающим индексам и почти не трогает сами таблицы, то речь менее чем о сотне мс. Суть в том, что агрерация идёт в pipeline mode по покрывающим индексам и на клиент уходит компактная свертка результатов в пару сотен строк. Если же делать по-вашему, то нужно выкачать несколько миллионов строк с дисков, отослать их на другой сервер и там повернуть ту же самую свертку в памяти в компактную таблицу, но без кучи оптимизаций по работе с общими буферами PG и буферами ОС. Если хотите, напишите предложение по тесту, я его прогоню по-своему и по-вашему.
По-хорошему, такие агрегаты должны храниться и обновляться отдельно если они действительно часто запрашиваться.
Напомню, речь шла не о редких аналитических запросах, а об основных запросах веб-приложения к базе. Такие запросы нельзя держать настолько сложными.
У вас в статье не шла речь про веб приложение, вы давали общие рекомендации. Я же вам привёл данные из работающей системы медицинских заказов на целый край. И это не редкий аналитический запрос, а типовая проверка для заказа направления между медицинскими учреждениями. Такие данные нельзя хранить отдельно и обновлять, они должны быть актуальны на любой момент времени. И они как то держатся настолько сложными и отлично работают в продакшене. Если вы пишите практики для простых веб приложений, то и указывайте об этом. Реальные промышленные системы обычно на порядок сложнее.
У меня в статье?
И, кстати, не вижу никаких причин, по которым данные, хранящиеся отдельно, не могут быть актуальными в любой момент времени.
Приношу извинения, автор не вы — пятница вечер))
Что вы подразумеваете под «хранящиеся отдельно»? Если речь про кеши, то аргумент трудно принять. Если про посчитанные агрегаты, то это не всегда применимо — для разных пользователей будут свои значения агрегатов в каждый момент времени, их нет смысла считать заранее.
Что вы подразумеваете под «хранящиеся отдельно»? Если речь про кеши, то аргумент трудно принять. Если про посчитанные агрегаты, то это не всегда применимо — для разных пользователей будут свои значения агрегатов в каждый момент времени, их нет смысла считать заранее.
это моя статья и там в названии сказано что она про сайт))))
система медицинских заказов на целый край хранит данные, наверное, в чем-нибудь максимально энтерпрайзном? я, к сожалению, не умею проводить «агрерацию в pipeline mode по покрывающим индексам» привычными для веба инструментами.
и какая, если не секрет, нагрузка на систему?
система медицинских заказов на целый край хранит данные, наверное, в чем-нибудь максимально энтерпрайзном? я, к сожалению, не умею проводить «агрерацию в pipeline mode по покрывающим индексам» привычными для веба инструментами.
и какая, если не секрет, нагрузка на систему?
Могу сказать за Oracle, что там сджойнивание таблиц за пределами базы — немыслимо чудовищный антипаттерн. Подозреваю, что и в PostgreSQL тоже.
Да это антипатерн для любой ДБ. Если быстрее делать join «руками» чем стандартными средствами БД, то, простите, зачем вообще такая БД нужна?
Вообще «никогда не делайте join руками, умные дяди-разработчики движкоа баз даных потратили миллион человекочасо что-бы делать это максимально эффективно» — это совершенно капитанский совет, референом звучащий в абсолютно любом «проблемы перформанса для детсадовцев».
Вообще «никогда не делайте join руками, умные дяди-разработчики движкоа баз даных потратили миллион человекочасо что-бы делать это максимально эффективно» — это совершенно капитанский совет, референом звучащий в абсолютно любом «проблемы перформанса для детсадовцев».
улыбнудо про «умных дядь-разработчиков».
вам, простите, приходилось поддерживать что-то со сходным с mysql-query-plan-builder legacy? Или с его же переменчивым набором требований? Как вы думаете, много там багов?
хотите влет пример JOIN, который я руками гарантированно сделаю быстрее, чем используемая на проде версия MySQL сервера?
вам, простите, приходилось поддерживать что-то со сходным с mysql-query-plan-builder legacy? Или с его же переменчивым набором требований? Как вы думаете, много там багов?
хотите влет пример JOIN, который я руками гарантированно сделаю быстрее, чем используемая на проде версия MySQL сервера?
Самое страшное во взрослении не то, что мы теперь взрослые, а то, что «умные дяди-разработчики» — это теперь мы.
Я же не спорю что вы получили пруф.
Но ето возможно только если вы неправильно «готовите» БД.
О обемах с которими работаю > 600 Gb OLTP база с некоторими елементами DW редологов за сутки около 50-80Gb. Да и вся бизнес логика >500 000 строк в БД. И ето все крутитца всего на 2 ядрах Power 7+. При етом некоторие запросы на несколько екранов и десятки таблиц. Перед етим я работал с MYSQL с базами > 50Gb правда и сервера были послабее. Но я не могу представить ситуацию когда обединение таблиц будет быстрее вне БД. ( ведь будут накладние расходы — сеть, преобразование)
Но ето возможно только если вы неправильно «готовите» БД.
О обемах с которими работаю > 600 Gb OLTP база с некоторими елементами DW редологов за сутки около 50-80Gb. Да и вся бизнес логика >500 000 строк в БД. И ето все крутитца всего на 2 ядрах Power 7+. При етом некоторие запросы на несколько екранов и десятки таблиц. Перед етим я работал с MYSQL с базами > 50Gb правда и сервера были послабее. Но я не могу представить ситуацию когда обединение таблиц будет быстрее вне БД. ( ведь будут накладние расходы — сеть, преобразование)
0.5M строк — это не показатели
это бизнес логика, а не строки в таблицах =)
Судя по "… редологов..", имеется ввиду Оракл, это его термин для бинарных логов.
А так да, join вне базы, это антипаттерн сравнимый с характеру с вашим примером «Проблема «n+1»»
Такая бомба замедленного действия.
Судя по "… редологов..", имеется ввиду Оракл, это его термин для бинарных логов.
А так да, join вне базы, это антипаттерн сравнимый с характеру с вашим примером «Проблема «n+1»»
Такая бомба замедленного действия.
Интересно, шардинг тоже антипаттерн?
Теплое с мягким не путаем =)
Я так понимаю Вы имеете ввиду, что у вас есть большая зашарденная табличка, а справочники лежат все на одном инстансе в одном месте, и вот потом Вы пытаетесь на клиенте сопоставить данные вытащенные с шардов с данными из справочников. И тут надо смотреть насколько эффективно Вы это делаете, может оказаться так, что дублирование справочников по шардам — может оказаться эффективнее централизованного хранения, а может и хуже.
Тут ведь проблема с JOIN на клиенте в объемах, которые вы пытаетесь обрабатывать. Грубо говоря, вы сделали запрос с фильтрацией (WHERE) в БД из основной таблицы, а потом начинаете в полном объеме (без WHERE) подтягивать справочники чтобы сделать ручной JOIN. И, ВДРУГ, в какой-то момент оказывается, что у справочники то большие, а в результате фильтрованного запроса часть данных справочника вообще не используется. И в итоге вы нагибаете базу заставляя её уходить в чтение с дисков на больших справочниках, нагибаете сеть — заставляя гонять кучу данных, нагибаете клиента — отъедая ОЗУ и проц на ручной JOIN.
А можно было сделать JOIN в БД и сразу отфильтровать только нужные данные.
В общем, складывается впечатление, что автор не смог разобраться с БД и почему там хреновый план выполнения запроса, и решил в лоб на клиенте сделать JOIN, потому что лень переписывать неэффективный SQL.
Я так понимаю Вы имеете ввиду, что у вас есть большая зашарденная табличка, а справочники лежат все на одном инстансе в одном месте, и вот потом Вы пытаетесь на клиенте сопоставить данные вытащенные с шардов с данными из справочников. И тут надо смотреть насколько эффективно Вы это делаете, может оказаться так, что дублирование справочников по шардам — может оказаться эффективнее централизованного хранения, а может и хуже.
Тут ведь проблема с JOIN на клиенте в объемах, которые вы пытаетесь обрабатывать. Грубо говоря, вы сделали запрос с фильтрацией (WHERE) в БД из основной таблицы, а потом начинаете в полном объеме (без WHERE) подтягивать справочники чтобы сделать ручной JOIN. И, ВДРУГ, в какой-то момент оказывается, что у справочники то большие, а в результате фильтрованного запроса часть данных справочника вообще не используется. И в итоге вы нагибаете базу заставляя её уходить в чтение с дисков на больших справочниках, нагибаете сеть — заставляя гонять кучу данных, нагибаете клиента — отъедая ОЗУ и проц на ручной JOIN.
А можно было сделать JOIN в БД и сразу отфильтровать только нужные данные.
В общем, складывается впечатление, что автор не смог разобраться с БД и почему там хреновый план выполнения запроса, и решил в лоб на клиенте сделать JOIN, потому что лень переписывать неэффективный SQL.
Про справочники — это ваши фантазии, как и про полный объем данных по связям без фильтрации.
На эту и смежные темы написаны сотни статей, подготовлены презентации для десятков конференций Highload и прочих
Если лень гуглить:
http://www.myshared.ru/slide/9793/ (слайд 38)
http://highload.guide/blog/sharding-patterns-and-antipatterns.html (к тезису про справочники, и вашему предположению, что все нужные данные на одном шарде)
На эту и смежные темы написаны сотни статей, подготовлены презентации для десятков конференций Highload и прочих
Если лень гуглить:
http://www.myshared.ru/slide/9793/ (слайд 38)
http://highload.guide/blog/sharding-patterns-and-antipatterns.html (к тезису про справочники, и вашему предположению, что все нужные данные на одном шарде)
Ох, мы опять про ежей и ужей. Вот эти вот «фантазии» почему то очень часто приходится разгребать, когда система «внезапно» перестает отвечать за вменяемое время.
Поглядел. И не понял почему они вообще решили при этом использовать реляционную БД. Выключить все что дает движок, и использовать СУБД как Key-Value хранилище к которому можно писать запросы на SQL, что выглядит мягко говоря странным, так как SQL это еще один дополнительный слой, который можно в такой системе выкинуть.
Давайте сразу определимся, есть хайлод в котором данные не важны, ну в некоторой степени не важны — потеряем мы комментарий пользователя, или данные сессии похерим, ничего страшного — пользователь перенаберет/перезайдет.
А есть хайлод в котором транзакции, ACID, нормализация и вот это вот все называемое реляционной моделью данных. А данные там критически важные — как самый яркий пример — финансовые транзакции. А теперь попробуйте объяснить заказчику системы, почему у вас данные не консистентны из-за того, что Вы не используете механизм транзакций. Или данные пропали, потому что не успели зафиксироваться на дисках. Или топовое серверное железо загибается, из-за того, что программер решил всю базу к клиенту гонять и обратно, вместо работы с данными в самой базе. И таких примеров много.
http://www.myshared.ru/slide/9793/ (слайд 38)
Поглядел. И не понял почему они вообще решили при этом использовать реляционную БД. Выключить все что дает движок, и использовать СУБД как Key-Value хранилище к которому можно писать запросы на SQL, что выглядит мягко говоря странным, так как SQL это еще один дополнительный слой, который можно в такой системе выкинуть.
Давайте сразу определимся, есть хайлод в котором данные не важны, ну в некоторой степени не важны — потеряем мы комментарий пользователя, или данные сессии похерим, ничего страшного — пользователь перенаберет/перезайдет.
А есть хайлод в котором транзакции, ACID, нормализация и вот это вот все называемое реляционной моделью данных. А данные там критически важные — как самый яркий пример — финансовые транзакции. А теперь попробуйте объяснить заказчику системы, почему у вас данные не консистентны из-за того, что Вы не используете механизм транзакций. Или данные пропали, потому что не успели зафиксироваться на дисках. Или топовое серверное железо загибается, из-за того, что программер решил всю базу к клиенту гонять и обратно, вместо работы с данными в самой базе. И таких примеров много.
Видимо мы разговариваем на разных языках…
Статья «Чек-лист по выживанию сайта».
Я про join и шардинг (не всегда данные влазят в одну базу и обилие join серьезно усложняет шардирование), а вы мне про справочники и транзакции.
Почему вы решили что я не использую транзакции, опять фантазия?
Не вижу смысла продолжать обсуждение.
Статья «Чек-лист по выживанию сайта».
Я про join и шардинг (не всегда данные влазят в одну базу и обилие join серьезно усложняет шардирование), а вы мне про справочники и транзакции.
Почему вы решили что я не использую транзакции, опять фантазия?
Не вижу смысла продолжать обсуждение.
Видимо да. Вы почему то уперлись в утверждение, что join на шардинге это плохо. И приводите в качестве аргумента вырванные из контекста слайды (отсюда и предположение что не используете транзакции, все таки презентация про конктретный случай, а не про общее состояние дел).
Просто Вы не хотите посмотреть шире, и рассматриваете шардинг как размазывание одного объекта по кучи хостов из которого «магическим» образом вытаскиваются данные, и накладывание не который JOIN чревато проблемами.
Но если посмотреть на шардинг как на комплекс независмых хостов, в каждом из которых есть все необходимые данные для работы хоста — то проблема джойнов исчезает. Вы просто заранее решаете какой хост предпочтителен в данном конкретном случае, для доступа к конкретным данным.
Просто Вы не хотите посмотреть шире, и рассматриваете шардинг как размазывание одного объекта по кучи хостов из которого «магическим» образом вытаскиваются данные, и накладывание не который JOIN чревато проблемами.
Но если посмотреть на шардинг как на комплекс независмых хостов, в каждом из которых есть все необходимые данные для работы хоста — то проблема джойнов исчезает. Вы просто заранее решаете какой хост предпочтителен в данном конкретном случае, для доступа к конкретным данным.
Ну наконец-то появился конструктив.
JOIN на шарде — вполне годная тема, особенно если архитектура изначально предрасположена к шардированию. Это не отменяет того, что возможно придется сделать довыборку данных из другого источника и в этом нет ничего страшного. Транзакции нужно использовать для финансовых операций с этим никто не будет спорить.
Есть другая крайность с которой мне приходится часто сталкиваться — 1 сервер БД который не в состоянии переварить все данные и запросы, блокировки и прочее. Когда приложение написано с огромным кол-вом объединений. Чтобы растащить такую базу нужно очень сильно поднапрячься. Именно поэтому в вебе join больше зло. Потому как даже просто вынос конкретной таблицы на отдельный сервер представляет сложную задачу.
JOIN на шарде — вполне годная тема, особенно если архитектура изначально предрасположена к шардированию. Это не отменяет того, что возможно придется сделать довыборку данных из другого источника и в этом нет ничего страшного. Транзакции нужно использовать для финансовых операций с этим никто не будет спорить.
Есть другая крайность с которой мне приходится часто сталкиваться — 1 сервер БД который не в состоянии переварить все данные и запросы, блокировки и прочее. Когда приложение написано с огромным кол-вом объединений. Чтобы растащить такую базу нужно очень сильно поднапрячься. Именно поэтому в вебе join больше зло. Потому как даже просто вынос конкретной таблицы на отдельный сервер представляет сложную задачу.
Ну да 0.5M строк кода на PL/SQL — не показатель :)
наибольшая табличка > 550 000 000 строк ежедевно увеличиваєтся 300 000 строк и ето не логи а таблица влияющая на остатки.
наибольшая табличка > 550 000 000 строк ежедевно увеличиваєтся 300 000 строк и ето не логи а таблица влияющая на остатки.
При работе с MySQL примитивно помогает увеличить скорость простановка LIMIT к запросам и fetch_assoc вместо более медленного fetch_array, создающего доп.элементы. По-моему, тюнинг баз — это отдельная тема, стоит ли веб-программистов за это сильно ругать?
Что такое "RDB таблица", которую нельзя использовать для организации очереди? Гуглится только RGB :-)
Простите, конечно же RDBMS
Забавно, что в первой части ActiveRecord упоминается как приводящий к проблеме "n + 1", а во второй — как отличный паттерн организации кода.
С бизнесом можно разговаривать только на языке бабла. Он не восприимчив к красоте решений, нормализации базы, CAP-теоремам и прочим IT-ценностям. Он понимает деньги и сроки.
Попытка спросить какую нормальную форму использкует разработчик или ваша БД приведена к третьей нормальной форме — как правило ставит в тупик. Люди не знают кто такой Эдгар Кодд!!! Поэтому есть СУБД, но баз данных нет. Отсюда все проблемы и так называемым электронныи правительством, госуслугами и т.д.
Dependency Injection — это паттерн, позволяющий легко подсовывать моки при юнит-тестах и/или строить приложение с помощью конфиг файла, в стиле ZF 1.x. Иначе — атипаттерн.
Святые, слова.
Расскажите это разработчикам Angular
Отличный материал, спасибо. Особенно согласен в плане взаимодействия с базой.
Буду ссылаться вместо того, чтобы каждый раз объяснять, почему до сих пор пишу все запросы руками.
В плане базы я бы сделал акцент на то, что большинство систем работают в основном на чтение (1 запись на 100 чтений). Поэтому простота чтения должна быть обеспечена в первую очередь. Академические нормальные формы, например, отношения many-to-many в отдельных таблицах, должны быть продуманы, нужны ли они вообще в каждом конкретном случае.
5 копеек про фронт: я бы выделил 3 периода: до jquery, с jquery, с mvvm (knockout/angular/react/vue). Если система не в 3-ем периоде и хочет развиваться, то нужно переходить. Внутри mvvm переход едва ли оправдан — несмотря на различную внутреннюю логику, нет ничего на angular/react, чего нельзя написать на старичке knockout в тех же строчках кода и той же сложности. Новеньким я бы советовал vue.js как последователя, который включил все лучшее от предшественников.
Фанаты реакт хвалятся виртуальным dom-деревом — мол самые затратные операции — операции с dom, поэтому прослойка, которая фильтрует изменения dom, делает реакт очень быстрым. Однако реакт тоже прекрасно вешается, если не думать. А если думать, то любая универсальная прослойка будет медленнее, чем нативный специализированный код, который не делает ничего лишнего.
Буду ссылаться вместо того, чтобы каждый раз объяснять, почему до сих пор пишу все запросы руками.
В плане базы я бы сделал акцент на то, что большинство систем работают в основном на чтение (1 запись на 100 чтений). Поэтому простота чтения должна быть обеспечена в первую очередь. Академические нормальные формы, например, отношения many-to-many в отдельных таблицах, должны быть продуманы, нужны ли они вообще в каждом конкретном случае.
5 копеек про фронт: я бы выделил 3 периода: до jquery, с jquery, с mvvm (knockout/angular/react/vue). Если система не в 3-ем периоде и хочет развиваться, то нужно переходить. Внутри mvvm переход едва ли оправдан — несмотря на различную внутреннюю логику, нет ничего на angular/react, чего нельзя написать на старичке knockout в тех же строчках кода и той же сложности. Новеньким я бы советовал vue.js как последователя, который включил все лучшее от предшественников.
Фанаты реакт хвалятся виртуальным dom-деревом — мол самые затратные операции — операции с dom, поэтому прослойка, которая фильтрует изменения dom, делает реакт очень быстрым. Однако реакт тоже прекрасно вешается, если не думать. А если думать, то любая универсальная прослойка будет медленнее, чем нативный специализированный код, который не делает ничего лишнего.
Пять копеек к проблеме большого количества select-update и локов.
Такая нагрузка на таблицу предполагает, что это явно не последняя таблица в проекте. И для оптимизации этих запросов вы готовы потратить времени чуть больше, чем просто создать пару индексов.
Тогда возможно стоит добавить микросервис (простой рест сервис) над этой таблицей, через который пойдут наиболее тяжёлые и частые запросы (select), пусть даже не все, и пусть там данные кэшируются хотя бы секунд 5-10 (20), и пусть он выполняет какие-нибудь несложные фильтрации с этими данными — разве это не стандартное решение для микросервисной архитектуры?
От мастер-слейв это решение отличается объёмом используемых ресурсов (микросервис будет сильно скромнее и более интегрированным в ваш проект и бизнес логику) и тем что вы получаете механизм регулирования нагрузки через изменения времени кеша.
Такая нагрузка на таблицу предполагает, что это явно не последняя таблица в проекте. И для оптимизации этих запросов вы готовы потратить времени чуть больше, чем просто создать пару индексов.
Тогда возможно стоит добавить микросервис (простой рест сервис) над этой таблицей, через который пойдут наиболее тяжёлые и частые запросы (select), пусть даже не все, и пусть там данные кэшируются хотя бы секунд 5-10 (20), и пусть он выполняет какие-нибудь несложные фильтрации с этими данными — разве это не стандартное решение для микросервисной архитектуры?
От мастер-слейв это решение отличается объёмом используемых ресурсов (микросервис будет сильно скромнее и более интегрированным в ваш проект и бизнес логику) и тем что вы получаете механизм регулирования нагрузки через изменения времени кеша.
Вопрос к обсуждению на стыке проблем с (избыточными) индексами и разрастанием БД:
Так ставить на этом поле индекс для ускорения работы скрипта-мусорщика или нет?
- Подопытный: MySQL 5.6
- Данные кешируются в набор однотипных таблиц с разделением по одной из характеристик данных
- У каждой записи есть поле с меткой времени Unix
- В нескольких самых больших таблицах в районе 1 млн записей, длина записи чаще всего 8...30 КБ
- Скорость записи данных в таблицы достигает до 6...10 зап/с
- Устаревшие данные, старее заданной временной метки и отвечающие определенному критерию, на регулярной основе удаляются 1 раз в сутки в момент минимальной нагрузки от посетителей скриптом, запускаемым по крону. Доля таких данных в общем объеме записей в заданном временном интервале (сутки за пределами заданной временной метки) составляет 5...50%
- Сейчас по этому полю индекса нет, т.к. фактически оно используется только для этой цели и еще сортировки результатов запроса DESC (99.99% случаев в результирующем сете 1 строка, но иногда может быть 2 или даже 3)
- Работа скрипта-мусорщика занимает 405...415 сек
Так ставить на этом поле индекс для ускорения работы скрипта-мусорщика или нет?
Работа скрипта-мусорщика занимает 405...415 сек
Все зависит исключительно от того, устраивает ли время работы мусорщика.
Если я правильно понимаю, то без этого индекса работа скрипта-мусорщика будет замедляться по мере разрастания таблиц (накопления данных, которые не подлежат удалению). В год добавляется примерно 200-300 миллионов записей, из них от 100-290 миллионов будут оставаться в базе навсегда.
Это довольно странная цифра, если вы говорите, что сейчас у вас всего миллион записей. Но если это правда — то за первый год мусорщик замедлится не менее чем в сотню раз, надо это учитывать.
Все зависит исключительно от того, устраивает ли время работы мусорщика.
Уже не устраивает, но не могу для себя решить, что важнее — мириться со временем работы мусорщика или добавлять накладных расходов к инсерту данных.
В год добавляется примерно 200-300 миллионов записей, из них от 100-290 миллионов будут оставаться в базе навсегда.
Сейчас годовой темп прироста 4...5 млн записей на 10+ таблиц с постоянной тенденцией к росту. Но Ваши цифры мне нравятся — заработки будут выше :)
Глубокой ночью раз в неделю зачищаются все данные к которым за последние 2 года не обращались повторно. Будет расти база — буду зажимать возраст невостребованных данных, но сейчас более 80% данных запрашиваются повторно хотя бы раз в интервале от 6 мес после добавления в БД (обсчитывал на дампе на ноуте, фиксируется только метка времени последнего обращения).
Если вас не устраивает время работы мусорщика — то без индекса вы ну никак не обойдетесь.
Что же до накладных расходов — то их можно быстро прикинуть сли знать сколько индексов уже есть. Если индексов нет — то считайте, что все операции вставки от появления первого индекса замедлятся в два раза. Если у вас десять индексов — то добавление одинадцатого замедлит вставки всего на 10%.
PS если вы думаете построить индекс по времени последнего чтения записи — то надо обновлять это поле только если обращений не было последний месяц
Это и есть главная проблема — таблицы объемные, но не очень сложные (8 полей) и работают на много-много простых запросов. Сейчас индексов на каждой таблице всего 3 (точнее 4 вместе с полем recid): 2 по полям varchar(20) и один по полю smallint. Индекс, с добавлением которого я раздумываю, будет по полю int(11).
Но пока что склоняюсь к тому, что лучше его добавить.
Но пока что склоняюсь к тому, что лучше его добавить.
Добавил на 19 таблицах индексы по полю с меткой времени Unix.
Этой ночью скрипт-мусорщик отработал за 234 сек вместо 405...415 сек ранее. Каких-то лагов с работой основного функционала не заметил. Дальше, похоже, надо переходить на хостинг с SSD. :)
Этой ночью скрипт-мусорщик отработал за 234 сек вместо 405...415 сек ранее. Каких-то лагов с работой основного функционала не заметил. Дальше, похоже, надо переходить на хостинг с SSD. :)
не задумывались о дополнительной таблице с префиксом zip?
Может вам шардирование поможет?
старее заданной временной метки и отвечающие определенному критерию
лично я бы организовал составной индекс — из timestamp и полей, участвующих в определенном критерии, если таковой индексируем.
Sign up to leave a comment.
Чек-лист по выживанию сайта