PS. Если наличие тега PostgreSQL более-менее оправдано (одна ссылка всё же есть), то тег MS SQL, походу, просто участвует в массовке.
Я впервые это делал на SQL Server, где-то 20 лет назад, тогда первыми кончились деньги на лицензии SQL Server Enterprise )) в котором была транзакционная репликация которая нужна для референсных табличек и традиционного партиционирования (куда же без него).
А воспользоваться фичей Federated tables из SQL Azure у нас не было возможности потому что Microsoft ее еще тогда не придумал ))
Кстати у меня тоже было пару таких собесов где кандидат явно транслировал все вопросы в ИИ и зачитывал мне его ответы как в вашем примере. Подозрение возникает сразу как только ты понимаешь что человек отвечает на все подряд вопросы, так с живыми людьми просто не бывает. А подтвердить подозрение можно как в вашем примере, попросив например пояснить что тут в коде почему и для чего написано ) и/или попросить вернутся на два шага назад и немного поменять условие задачи (тут видимо ИИ несколько теряется) в моем случае человек казалось забыл все что только что мне со знанием дела рассказывал, как будто ему отключили мозг.
Предположим у вас два узла с данными и плюс узел который играет роль координатора;
Координатор может быть специальным прокси (как у вас) или просто немного необычным бизнес сервисом который сам по себе умеет в шардинг;
Предположим вам нужна третья страница из ленты заказов отсортированных по дате обратном порядке;
Координатор получив запрос пользователя транслирует его в каждый из узлов данных изменив границы страницы; Вы не знаете сколько данных у вас на каждом из узлов поэтому чтобы вырезать третью страницу вам нужно запросить с первой строки по N, где N = размер страницы * номер страницы + 1 (чтобы знать есть ли еще данные соотвествующие критерию поиска в этом узле с данными)
Получив результаты от всех узлов с данными координатор объединяет результаты одновременно выполняя сортировку в один проход (ведь данные с узлов с данными возвращаются уже локально, для узла отсортированными)
Получив общий и теперь глобально отсортированный список записей полученных со всех узлов с данными Координатор вырезает новую третью страницу и возврщает ее пользователю;
И все вполне консистентно, по крайней мере до той же степени до которой констентен read consistency )
тут явная подмена декларируемой и реальной целей. люди хотят писать на Rust, он им нравится ) но они не могут написать "вот мы решили написать свое ядро на Rust, потому что Rust выбросили из ядра", это же никому кроме них самих интересно не будет )
то что безопасность не сводится к безопасному управлению памятью, и в целом к использованию везде паттерна RII, они скромно умалчивают, хотя, конечно могут и добросовестно заблуждаться...
>> Я надеюсь что и правда все понятно, потому что из текста не могу считать сарказм это или нет :) Лучше уточнить
Нет, все и правда понятно. Спасибо за ссылку.
>> Вы сейчас описываете аналитический сценарий.
Ну почему же "аналитический" , вот возьмем eCom, есть роль кастомера и его заказы, и есть роль менеджера который обрабатывает заказы. Предположим заказы шардированы по регионам (как я писал выше на самый идеальный выбор, но тут идеального вообще не может быть) и у пользователя в профиле выбран какой-то регион. Значит для отображения списка его заказов вы всегда знаете ключ шардирования, но вот для менеджера магазина который обрабатывает заказы (не анализирует а именно что-то с ними делает, то есть это именно OLTP) и которому нужно отобразить ленту заказов отсортированных по дате (последние выше) ключ шардирования по региону вообще не подходит потому ему нужно видеть заказы сделанные в любом регионе. Не согласны?
1) Ммм, ... Шаг 1 - поделить общую схему БД на логически замкнутые подсхемы (нет запросов в join-ами) выходящими за подмножесто таблиц входящих в подсхему. (И да потребуется легкая доработка Data access layer в приложении), в общем выполнить то что иначе называется вертикальным партиционированием. Очень часто этого шага уже хватает и вы можете использовать паралельно два / три HA кластера серверов СУБД
Шаг 2 - если после шага 1 все еще остались таблички которые с трудом ворочаются имеющимися в наличии серверами БД, выполнить шардинг (или горизонтальное партиционирование) поделить тяжелые таблички (со своим чайлд табличками) по серверам таким образом что данные одного типа (например заказы) хранятся сразу на нескольких серверах каждый из которых является мастером и хранит данные в единственном экземпляре (на другие мастера не реплицируется). И вот тут да, доработки DAL чуть чуть посложнее и возникает идея про прокси. Отсюда растут Azure SQL, Greenplum, Citus, MySQL Proxy ну и все что возникло позже включая видимо и SPQR) Проблема в том что очень часто на шаге #1 можно остановится и/или на шаге 2 выбрать какой-то NoSQL (Mango, Cassanra)
2) Все понятно
3) Может ведь быть (и часто бывает) что природа запроса такова что данные невозможно отнести к какому-то шарду. Например у вас есть сущность "Заказы" и вы выбрали ключ шардирования - "регион" (сомнительный выбор, но допустим) и вам (по бизнес требованиям) нужно найти все заказы за последние 5 минут с сортировкой по дате и пейджингом. Очевидно чтобы это сделать потребуется сходить во все шарды получить заказы за последние 5 минут, обьеденить в общий список, заново отсортировав его по дате, вырезать из него заказанную страницу и вернуть на фронт; Помогает ли SPQR решать такую задачу?
Если вы смотрите на это именно так то выбирать разумеется нужно надежные и прибыльные профессии ) для разработчиков это не только профессия но и увлечение, а для увлечения чем не пожертвуешь
Я бы суммировал прочитанное так: у компаний в условиях кризиса снизился горизонт планирования и они пытаются решать только проблемы которые возникают здесь и сейчас. Сейчас нет ресурсов чтобы заниматься RnD (учить джунов ) и это в перспективе 2-3 лет снова приведет к недоступности квалифицированных ресурсов для внутреннего рынка труда.
На моей памяти это было уже три раза (((
ЗЫ : Только скорее всего яма будет в это раз побольше, из за разрушения текущих завышенных ожиданий от ИИ.
Если суммировать смысл статьи, то остается только преимущество по стоимости и оно действительно есть, даже с учетом использования платной версии PostgreSQL Pro.
Вроде получается что статья не совсем техническая? )
P.S. И честно говоря хранения в колонках JSON / BSON и всякого другого текста содержащего частично структурированные данные - это разумеется анти-паттерн, особенно в PostgreSQL из за особенностей его реализации (https://www.postgresql.org/docs/current/storage-toast.html)
Легко понять что преждевременная оптимизация приводит к таким же результатам как отсутствие оптимизации, для этого достаточно вспомнить что ресурсы используемые для создания программы всегда ограниченны.
Начали оптимизировать до того как поняли где же находятся ботлнеки системы — потратили время бесполезно. Пришло время релиза и откладывать уже ничего нельзя, система выходит как есть.
Речь не о том чтобы модифицировать стандартный класс или дописывать в него метод, а о том что необязательно составлять название метода из 9 слов, чтобы сделать его информативным.
Эмм… все перечисленное безусловно про деньги. То что это не про деньги Вас могут лечить добрые дяди с толстыми кошельками которые «от души» вынимают малую копеечку из своего кошелёчка и подают Вам на пропитание пока вы занимаетесь тем что Вам нравится. А вот когда из Вашего проекта что-то получится, ну может не из вашего а из проекта вашего товарища вот тогда они с удовольствием на этом проекте заработают денежку, причём так что Вы лично будете думать что осчастливили человечество.
Это всего лишь означает что у StreamReader неудачное API.
А то что в документации не слова про неявную функциональность как раз доказывает то что наличие документации и комментариев не обязательно делает код понятнее.
Как написано у Роберта Мартина в Clean code, ошибка может быть как в коде так и в комментариях.
Причём при исправлении бага или при добавлении новых функций комментарий может остаться не исправленным или не дополненным как видимо подучилось с методом Peek()
Вообще то что хороший код не нуждается в комментариях это цитирование одного из тезисов из книжки Clean code за авторством Robert Martin человека весьма уважаемого и без всякого сомнения зрелого.
По моему, проекты это прежде всего про людей и только во вторую очередь про технические сложности.
Если проект становится не успешным, это не потому что команда встретилась с технической сложностью. Но различное понимание ключевыми стэйкхоледами функциональности будущей системы вполне может к этому привести. Перфекционизм и стремление разработчиков сделать все по правилам может значительно отложить запуск. Карьерные амбиции вновь назначенного менеджера проекта могут привести к тому что ничего не будет готово даже за втрое больший срок.
Стремление молодого и талантливого архитектора опробовать новые модные технологии может привести к неожиданно резкому увеличению бюджета вместо ожидаемой экономии.
Тихий саботаж со стороны сотрудников которых планируется уволить после запуска системы, и которых кто-то додумался включить в проектную команду, может привести к тому система вообще никогда не будет запущена.
В целом практики аджайл преследуют ровно две цели обьединить участников проекта общей целью и жестко контролировать расходы (на выходе из каждой итерации всегда есть шанс бросить вкладывать деньги в гнилое дело).
исправлены опчепятки, спасибо за замечания @vasilisc
А если юзер захочет пойти на предпоследнюю страницу? А шардов много, и записей ещё больше...
все так, я же написал об этом в минусах;
PS. Если наличие тега PostgreSQL более-менее оправдано (одна ссылка всё же есть), то тег MS SQL, походу, просто участвует в массовке.
Я впервые это делал на SQL Server, где-то 20 лет назад, тогда первыми кончились деньги на лицензии SQL Server Enterprise )) в котором была транзакционная репликация которая нужна для референсных табличек и традиционного партиционирования (куда же без него).
А воспользоваться фичей Federated tables из SQL Azure у нас не было возможности потому что Microsoft ее еще тогда не придумал ))
Кстати у меня тоже было пару таких собесов где кандидат явно транслировал все вопросы в ИИ и зачитывал мне его ответы как в вашем примере. Подозрение возникает сразу как только ты понимаешь что человек отвечает на все подряд вопросы, так с живыми людьми просто не бывает. А подтвердить подозрение можно как в вашем примере, попросив например пояснить что тут в коде почему и для чего написано ) и/или попросить вернутся на два шага назад и немного поменять условие задачи (тут видимо ИИ несколько теряется) в моем случае человек казалось забыл все что только что мне со знанием дела рассказывал, как будто ему отключили мозг.
Дальше примерно так:
Предположим у вас два узла с данными и плюс узел который играет роль координатора;
Координатор может быть специальным прокси (как у вас) или просто немного необычным бизнес сервисом который сам по себе умеет в шардинг;
Предположим вам нужна третья страница из ленты заказов отсортированных по дате обратном порядке;
Координатор получив запрос пользователя транслирует его в каждый из узлов данных изменив границы страницы; Вы не знаете сколько данных у вас на каждом из узлов поэтому чтобы вырезать третью страницу вам нужно запросить с первой строки по N, где N = размер страницы * номер страницы + 1 (чтобы знать есть ли еще данные соотвествующие критерию поиска в этом узле с данными)
Получив результаты от всех узлов с данными координатор объединяет результаты одновременно выполняя сортировку в один проход (ведь данные с узлов с данными возвращаются уже локально, для узла отсортированными)
Получив общий и теперь глобально отсортированный список записей полученных со всех узлов с данными Координатор вырезает новую третью страницу и возврщает ее пользователю;
И все вполне консистентно, по крайней мере до той же степени до которой констентен read consistency )
тут явная подмена декларируемой и реальной целей. люди хотят писать на Rust, он им нравится ) но они не могут написать "вот мы решили написать свое ядро на Rust, потому что Rust выбросили из ядра", это же никому кроме них самих интересно не будет )
то что безопасность не сводится к безопасному управлению памятью, и в целом к использованию везде паттерна RII, они скромно умалчивают, хотя, конечно могут и добросовестно заблуждаться...
>> Я надеюсь что и правда все понятно, потому что из текста не могу считать сарказм это или нет :) Лучше уточнить
Нет, все и правда понятно. Спасибо за ссылку.
>> Вы сейчас описываете аналитический сценарий.
Ну почему же "аналитический" , вот возьмем eCom, есть роль кастомера и его заказы, и есть роль менеджера который обрабатывает заказы. Предположим заказы шардированы по регионам (как я писал выше на самый идеальный выбор, но тут идеального вообще не может быть) и у пользователя в профиле выбран какой-то регион. Значит для отображения списка его заказов вы всегда знаете ключ шардирования, но вот для менеджера магазина который обрабатывает заказы (не анализирует а именно что-то с ними делает, то есть это именно OLTP) и которому нужно отобразить ленту заказов отсортированных по дате (последние выше) ключ шардирования по региону вообще не подходит потому ему нужно видеть заказы сделанные в любом регионе. Не согласны?
1) Ммм, ... Шаг 1 - поделить общую схему БД на логически замкнутые подсхемы (нет запросов в join-ами) выходящими за подмножесто таблиц входящих в подсхему. (И да потребуется легкая доработка Data access layer в приложении), в общем выполнить то что иначе называется вертикальным партиционированием. Очень часто этого шага уже хватает и вы можете использовать паралельно два / три HA кластера серверов СУБД
Шаг 2 - если после шага 1 все еще остались таблички которые с трудом ворочаются имеющимися в наличии серверами БД, выполнить шардинг (или горизонтальное партиционирование) поделить тяжелые таблички (со своим чайлд табличками) по серверам таким образом что данные одного типа (например заказы) хранятся сразу на нескольких серверах каждый из которых является мастером и хранит данные в единственном экземпляре (на другие мастера не реплицируется). И вот тут да, доработки DAL чуть чуть посложнее и возникает идея про прокси. Отсюда растут Azure SQL, Greenplum, Citus, MySQL Proxy ну и все что возникло позже включая видимо и SPQR) Проблема в том что очень часто на шаге #1 можно остановится и/или на шаге 2 выбрать какой-то NoSQL (Mango, Cassanra)
2) Все понятно
3) Может ведь быть (и часто бывает) что природа запроса такова что данные невозможно отнести к какому-то шарду. Например у вас есть сущность "Заказы" и вы выбрали ключ шардирования - "регион" (сомнительный выбор, но допустим) и вам (по бизнес требованиям) нужно найти все заказы за последние 5 минут с сортировкой по дате и пейджингом. Очевидно чтобы это сделать потребуется сходить во все шарды получить заказы за последние 5 минут, обьеденить в общий список, заново отсортировав его по дате, вырезать из него заказанную страницу и вернуть на фронт; Помогает ли SPQR решать такую задачу?
1) поясните пожалуйста все же про миграции, как ваше решение их упрощает?
2) как решается задача с lookup таблицам содержимое которых на всех шардах должно быть идентичным?
3) как решается задача с запросами в которых нет ключа шардирования?
Если вы смотрите на это именно так то выбирать разумеется нужно надежные и прибыльные профессии ) для разработчиков это не только профессия но и увлечение, а для увлечения чем не пожертвуешь
Я бы суммировал прочитанное так: у компаний в условиях кризиса снизился горизонт планирования и они пытаются решать только проблемы которые возникают здесь и сейчас. Сейчас нет ресурсов чтобы заниматься RnD (учить джунов ) и это в перспективе 2-3 лет снова приведет к недоступности квалифицированных ресурсов для внутреннего рынка труда.
На моей памяти это было уже три раза (((
ЗЫ : Только скорее всего яма будет в это раз побольше, из за разрушения текущих завышенных ожиданий от ИИ.
Если суммировать смысл статьи, то остается только преимущество по стоимости и оно действительно есть, даже с учетом использования платной версии PostgreSQL Pro.
Вроде получается что статья не совсем техническая? )
P.S. И честно говоря хранения в колонках JSON / BSON и всякого другого текста содержащего частично структурированные данные - это разумеется анти-паттерн, особенно в PostgreSQL из за особенностей его реализации (https://www.postgresql.org/docs/current/storage-toast.html)
Начали оптимизировать до того как поняли где же находятся ботлнеки системы — потратили время бесполезно. Пришло время релиза и откладывать уже ничего нельзя, система выходит как есть.
Хотя в случае С#, как раз есть extension methods…
docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/extension-methods
А то что в документации не слова про неявную функциональность как раз доказывает то что наличие документации и комментариев не обязательно делает код понятнее.
Как написано у Роберта Мартина в Clean code, ошибка может быть как в коде так и в комментариях.
Причём при исправлении бага или при добавлении новых функций комментарий может остаться не исправленным или не дополненным как видимо подучилось с методом Peek()
Если проект становится не успешным, это не потому что команда встретилась с технической сложностью. Но различное понимание ключевыми стэйкхоледами функциональности будущей системы вполне может к этому привести. Перфекционизм и стремление разработчиков сделать все по правилам может значительно отложить запуск. Карьерные амбиции вновь назначенного менеджера проекта могут привести к тому что ничего не будет готово даже за втрое больший срок.
Стремление молодого и талантливого архитектора опробовать новые модные технологии может привести к неожиданно резкому увеличению бюджета вместо ожидаемой экономии.
Тихий саботаж со стороны сотрудников которых планируется уволить после запуска системы, и которых кто-то додумался включить в проектную команду, может привести к тому система вообще никогда не будет запущена.
В целом практики аджайл преследуют ровно две цели обьединить участников проекта общей целью и жестко контролировать расходы (на выходе из каждой итерации всегда есть шанс бросить вкладывать деньги в гнилое дело).