._.
Нода как-бэ асинхронная, но потом она всётаки синхронная... и это влияет на производительность.
Берём профилятор и смотрим что где и как блокируется, а то блин звучит реально тупо...
Ещё тупее утверждать что каждый поток блокируется на время запроса к БД - это уже зависит от криворукости разработчиков самого драйвера и разработчиков приложения, как никак Unit Of Work никто не отменял.
Даже в случае с той же Java ЛЮБОЙ запрос в бд синхронен, и не важно сколько асинхронных обвёрток вокруг JDBC налепят - всеравно поток будет блокирован на время выполнения запроса, просто потому что асинхронного JDBC тупо нет в природе. И так сложилось исторически, и это отнюдь не означает что это решение не оптимально и что всё что "блокирует поток" заставляет ваш процессор простаивать, это очень глупый предрассудок дилетантов.
Ну вот к примеру в golang'е достаточно новый и стабильные драйвер lib/pq написан синхронным не потому что это "неоптимально", а просто по привычке и с пониманием того что в ядре ОС тоже есть свой планировщик, и что если нужно то он тоже не будет зря щёлкать процессорные такты, напротив тут приветствуется использование unit of work.
Просто советую почитать спецификацию процессоров и глянуть что ни в K ни в T vPro нету, но это отнюдь не означает что с ними не будет работать AMT 6-7, а вот для 8-9 нужна поддержка vPro со стороны процессора ...
Артем: вообще-то суффикс процессора S указывает на возможность применения в слабых рабочих станциях и поддержку vPro. Собственно vPro это просто набор технологий AMT является частью vPro. Сейчас для поддержки AMT 8+ нужен как раз таки Q* чипсет, и *S процессор.
Использую 2 рабочих станции на vPro, пока особо разницы с HP'шным сервером не заметил.
Пока ничего новее Q87 для рабочих станций не выходило, можно конечно смотреть в сторону С226 (у 224 нету vPro), не понятно в каком месте он устарел ?
kirigosh: на примере украинского законодательства могу сказать что расстаможка нового макбука стоит 800$, а доставка по воздуху - 250$. У One Plus не существует официальных каналов поставки - сравнивать некорректно. В случае с разработкой и проектированием ноутбуков - нужна туча лицензий, просто взять и продать китайский ширпотрёп не получится.
Ян Ко: я работал с решениями Oracle и Sybase некоторое время, могу сказать что там ситуация обстоит так, что вендоры ещё и заинтересованы в том что бы ничего не "опопсело", и они могли продать наиболее актуальную информацию и подходы к работе своих же продуктов.
Ян Ко: да, я прекрасно понимаю что у большинства разработчиков сейчас знания работы баз данных даже не дотягивают до второго курса университета. К сожалению, подобное рас.. яйское отношение сказывается на возможности масштабирования и долгосрочной поддержке продукта, ну у нас тут в постсовке "после нас хоть потоп" так что, в принципе, это предсказуемо и совсем не удивительно. Многие проекты начинали с очень плохой модели БД, и на ней всё и заканчивалось...
Dramatik: такое бывает довольно редко и нужно хорошо всё разложить по полочкам прежде чем начинать что либо делать - уж больно сильно много времени и денег люди тратят когда неправильно изначально формулируют задачи ввиду недостатка компетенции или плохого анализа и оценки рисков.
un1t: за "join по нескольким серверам" нужно лишать детородных органов. Большую часть агрегации, репликации и шардинга все равно приходится реализовывать со стороны приложения и в виде кастомных функций, иногда даже приходится прикручивать индексы на MVP и X деревьях. Особенно весело с live migration'ами когда нужно переносить данные с одной БД в другую что бы равномерно распределить нагрузку и снизить задержки на обработку запросов, но до этого простые смертные обычно никогда не доходят.
Kir ---: потому что там проблемы с блокировками табличек во время подчистки WAL журналов, раньше с этим боролся pg_reorg, сейчас более-менее нормально справляется pg_repack https://github.com/reorg/pg_repack
p.s. JSON в Postgre довольно эффективен так как в нём есть встроенный Flyweight, и для мелких баз PostgreSQL'ный JSON под gin индексом быстрее чем B-tree индексы MongoDB. Gin индексы по массивам строить можно, но редко когда не нужно... Фраза "JOIN'ы не масштабируются" просто рассмешила.
Kir ---: есть такие вещи как DEFERRABLE INITIALLY DEFERRED, DEFERRABLE INITIALLY IMMEDIATE, NOT DEFERRABLE, а вот MySQL'е их нет :) И всё по умолчанию INITIALLY DEFERRED, так что синхронизация чего либо в случае с репликацией чего либо просто не предусмотрена.
He11ion дешёвые думающие что знают MySQL обычно не знают что такое четвёртая нормальная форма - оно того просто не стоит. На практике за 7 лет разработки различных проектов, мне только 5 раз встречалась действительно хорошая модель в 6ой форме, всё остальное шлак и ширпортеп который и до третей не дотягивает.
Прежде чем денормализировать модель нужно её полностью нормализировать и произвести профилирование наиболее частых запросов, как показывает практика денормализация действительно необходима в очень редких случаях, а сейчас, в случае с PostgreSQL и местным Flyweight'ом и материализованными представлениями вообще уходит на второй план.
evnuh я что-то кому-то должен ? Я не обязан подтверждать своё личное субъективное мнение, если вы хотите бэнчмарков и детального анализа - делайте сами, пишите на хабр, флаг вам в руки.
Да, асинхронная потоковая репликация в мускуле есть, можно даже всякие Galera и прочие крутить, но на практике нужно ещё разобраться как происходит профилирование и разбор запросов, иногда мускуль пускает кони и там индексы криво мерджаться, неправильно проставляются метки векторных часов... в общем отдельно нужно прогонять нагрузочные тесты и фаззинг, а потом выясняется что лучше всё таки решать эти все вопросы на стороне приложения. В общем там ещё есть сложности в зависимости что нужно масштабировать - для масштабирования чтения свои приколы, а для масштабирования записи свои.
Kir --- ну значит не было БД больше 100Гб на одну реплику и 20Гб на шард, таблички не подтекали, а Autovacuum срабатывал как надо, и трафа было не так уж и много... Когда стоит вопрос низкоуровневой оптимизации - доков реально не хватает, и много что нужно выковыривать прямо в исходниках. А с коробки PostgreSQL настроен совсем не ахти. Есть книга "Администрирование PostgreSQL", но там всё очень и очень поверхностно описано, и даже офф доки не везде актуальны (
Почти со всем согласен... но есть одно большое НО.
Для PostgreSQL'я нет литературы и примеров использования для "чайников" со всеми особенностями.
А для MySQL слишком много лабуды, и только одна нормальная книжка по оптимизации где объясняется как там всё под капотом работает (Highload Mysql).
Dramatik: написал большую часть логики для RTB Optimizer в Datacratic вместе с Джереми Барнсом, через полгода внедрил туда же Deep Learning алгоритмы на GPGPU и отрефакторил всё на чистое С (без плюсов). Получаю процент с их месячного дохода и горя не знаю. Сейчас участвую в разработке площадки SoMuchMore - рефакторю всё что только под руку попадает, но ситуация там реально не ахти и до полноценного релиза ещё нужно решить слишком много проблем, в том числе и юридического плана.
Нода как-бэ асинхронная, но потом она всётаки синхронная... и это влияет на производительность.
Берём профилятор и смотрим что где и как блокируется, а то блин звучит реально тупо...
Ещё тупее утверждать что каждый поток блокируется на время запроса к БД - это уже зависит от криворукости разработчиков самого драйвера и разработчиков приложения, как никак Unit Of Work никто не отменял.
Даже в случае с той же Java ЛЮБОЙ запрос в бд синхронен, и не важно сколько асинхронных обвёрток вокруг JDBC налепят - всеравно поток будет блокирован на время выполнения запроса, просто потому что асинхронного JDBC тупо нет в природе. И так сложилось исторически, и это отнюдь не означает что это решение не оптимально и что всё что "блокирует поток" заставляет ваш процессор простаивать, это очень глупый предрассудок дилетантов.
Ну вот к примеру в golang'е достаточно новый и стабильные драйвер lib/pq написан синхронным не потому что это "неоптимально", а просто по привычке и с пониманием того что в ядре ОС тоже есть свой планировщик, и что если нужно то он тоже не будет зря щёлкать процессорные такты, напротив тут приветствуется использование unit of work.