Проблема в том, что заигрывая с санкциями США пытаются аннулировать материальную ответственность Microsoft в контрактных обязательствах, за которые фирма получила от России колоссальные деньги в твердой валюте. По сей причине России надо немедленно бежать от продуктов и Microsoft и Open Source. Поскольку не сегодняшний день заключенные ( и очень дорого оплаченные ) контракты не стоят бумаги на которой написаны.
Я так и не понял, может пропустил, что или как победило дубликаты. Придется перечитать ещё разок, чтобы добраться до золотой сути. Может она даже где — то там и есть.
Вообще, проблема мне кажется в двух основных свойствах Кафка. Первое, это бесплатный продукт. Поэтому его commit это вещь совершенно эфемерная. То есть даже если в коде стоит «noop», то с точки зрения Кафка, это приемлемо. Ведь не секрет, что Американская фирма по производству батареек на заре своего существования укладывала в корпус батареек грунт со двора предприятия, и пользуясь колоссальной дешевизной исходного сырья продавала свои изделия за половину стоимости конкурентов.
По сей причине повторяющийся припев писателя, что мол «но ведь это не применимо, там, где речь идет о деньгах вкладчиков» слушается с юмором. Это конечно очень хорошо, что автор это понимает. Но как — то вот это самое понимание с действиями вместе не очень консистентно.
Вторая, если мое очень поверхностное знакомство с Кафкой я запомнил верно, у Кафка есть возможность воспользоваться разными носителями для хранения записей. По умолчанию она воспользуется файловой системой. И тут commit очень сильно зависит от файловой системы, и даже сборки машины, которая её обеспечивает. Но есть возможность и воспользоваться СУБД. Тем самым открывая доступ к хорошо проверенному механизму обеспечения операции commit. Но тогда КАФКА становится ни чем иным, как ширмой для СУБД.
Что касается скорости обработки пакетов, то простейшая extended procedure на с для Microsoft SQL Server с одним CPU Pentium 2.0 и 1 GB памяти поддерживал производительность 60,000 пакетов в секунду.
То есть в принципе статья конечно полезная, автору огромное спасибо. Но умудриться так долго говорить о дубликатах и производительности, не приведя ни одного эксперимента ( а для сравнения их нужно как минимум два ) получается двойственное ощущение богатого материала и отсутствия сути.
Это когда у репозитория один пользователь на проэкте.
Вообще, если взглянуть на Git как на классическую утилиту, то её главный выигрыш это замечательный алгоритм распознавания изменений. То есть если забыть о проэктах и вернуться к рациональному и непредвзятому мышлению удивляющегося и любопытного ребёнка, то Git это идеальное устройство, чтобы сделать копию какого ни — будь гигантского проэкта, потом наложить на его корневую директорию Git repository, после чего опять же скопировать поверх этого самого проэкта тот же самый проэкт, но, допустим, от другого автора. В тот момент, когда последний файл закончит копирование, Git будет готов ответить на запрос, «есть ли разница». Изощренный пользователь может создать ветвление и построить pull request, для наглядности.
Ого, ничего себе, маркетологом меня еще никто не обзывал. И что же я рекламирую? MySQL? Мне наверное Oracle платит? :)
Почему «обзывал». Это прибыльное дело. Вы пишете не профессиональные комментарии, не несущие никакой информации, кроме личных выпадов и цитат из рекламных пособий фирмы производителя ПО.
Я не преследую цели сказать хорошее или плохое о той или иной СУБД. Информация о том, что «MySQL ( недавно ) выпустила новые фитчи для репликации, которые сделали её доступной.» является, не прямой, но цитатой из блога производителя ПО MySQL, представителя команды инженеров из базы данных дефектов.
Вообще после глубокого анализа статьи я пришел в выводу, что Uber видимо вернется к Postgress. После глубокого анализа я пришел к выводу, что выбор Postgress не был случайным или результатом hipe. Расчет был холодный, оправданный и похоже худо ли бедно ли, но бизнес был доволен пакетом ПО. Для этого есть объективные причины инженерного характера, которые без Postgress не решить. Моя оценка за 3 года фирма вернуться к Posgress не сможет, из-за возможной потери лица, но больше 5 лет без него прожить не сможет.
10 лет или даже 20 лет назад.
После того как MySQL отдали InnoDB, коммерческий продут, а Оракл купила MySQL, примерно год — два назад MySQL выпустила новые фитчи для репликации, которые сделали её доступной. Они до сих пор глючат. Я это говорю не для того, чтобы сказать, что MySQL плох или хорош. Ваши утверждения носят характер маркетинговой рекламной кампании. Вам здесь не место. Занимайтесь этими глупостями в статьях, за которые Ваша фирма платит.
Все это хорошо, но как решить, особенно в web приложении, кому поручить дождаться промис. Ведь есть соблазн делегировать его ожидание процессу, и тогда скрипач ( await ) не нужен.
И получается то, что у меня творится на web клиенте почты. Которая то повиснет, то не готова выполнять какие — то запросы, после первого запроса. Что же… выполняешь запрос во второй — третий — иногда четвертый раз. По мере того, как их «резиновая» виртуальная машина прогревает под мои запросы каши, они начинают работать.
И получается что пропустив await, его совсем даже не пропустили, а просто передали в руки конечного пользователя. Зато, я почти уверен, все показатели performance dashboard у разработчика пакета ПО зашкаливают.
«Назовите мне...»
***
Экий Вы п-п-п-п-простачек, от английского слова «новичок».
С такими п-п-п-простачками заикой стать можно. У компании Microsoft в контракте с пользователем записан «indemnification clause». Ищите перевод.
Господи, что делать с дилетантами. Они же все и всех убьют и скажут, что действовали во благо человечества. Чем они успешно и занимаются по всему миру.
Разговор идет не о «сейчас/сегодня» а о «хайповой библиотечки, которая только », и как Postgres выглядит на фоне лучших производителей СУБД.
Взять эталон индустрии разработки ПО. Microsoft SQL Server — физическая репликация ( mirroring ) появилась только с Service Pack 1 SQL Server 2008, то есть в 2010-м, мульти — узловая физическая репликация с доступом для чтения резервной копии в версии 2012, ошибки, которые лишали её возможности нормально работать поправили только в SP2, выпущенного 12-го Июля 2016-го года.
Сравнивая поддержкой репликации СУБД Postgres, мне кажется критика «хайповой библиотечки, которая только » не только не обоснована, но совершенно не отражает реальность.
«Uber еще замечает, что вообще у них были длинные транзакции в основном по вине разработчика.»
— и как это поможет исправить переход на MySQL?
Если эту фразу интерпретировать, как «Ну Uber сами дураки», то можно тушить свечи. А так… Общее ощущение что молодые ребята вкалывают, принимают волевые решения. Удачи.
Что до смены версий, разворачивать репликацию для перехода на новую версию это конечно один из подходов, но сказать чтобы это было интересно я не могу. Развертка триггеров дело вполне по плечу среднему разработчику, и сделать скрипт для перехода на обновленную версию дело не сложное. Видимо были какие — то другие приоритеты. Может им кто — то за перехода на MySQL обещал грант подкинуть на разработку робота — водителя, или помочь замять дело с недавней гибелью человека.
Постгрес как база лучше чем MySQL. Это однозначно. И кластеред индекс у неё есть. Автор лукавит. Это создаваемая по умолчанию секвенция строк. Выход на неё по бинарному древу поиска там по — моему с 7-й версии. В общем улучшение репликации пожалуй существенная вещь, но сказать, чтобы она была решающей трудно.
Я ничего не недоговариваю. Все как есть и как было. Гит не несет ответственности. Вообще ни за что. Кроме одного. Прибыль владельца. Единственная корпорация с полной ответственностью за все владения каждого человека в истории человечества была и будет СССР.
По поводу ГОСТ Вас неверно информировали.
По остальному, циско здесь в США, специально для таких вот приставок и прочего ширпотреба, создал отдельные бренды, которые в витринах под видом дочерних компаний, но на самом деле делается из комплектующих второго и третьего сорта ( которые летят ОТК «в пределах» ). Тут дело в наклейках. Ну а глючит у всех.
И даже не в этом дело. Мы ведь здесь на хабре, отдела кадров у Вас нет. И я могу Вам сказать прямо, в чем проблема. Есть такое понятие, описываемое английским словом liability. По — русски его переводят «ответственность». В Гите её за исчезновение собственности клиента, никто ни перед кем не несёт. От слова вообще.
Вообще — то это файловая система тоже не хранит записи о переименовании того или иного файла. Во всех без исключения репозиториях эти детали являются частью протокола изменения имени/переноса файла, который создан человеком, и интерпретируется в свою очередь, графическим приложением-клиентом не из той или иной «команды», но из определенного набора шагов, с определенными комментариями или тегами, которые автоматически поддерживает графическое приложение.
Что Гит не может вообще, это сделать древо из изменения имени одного файла. Ему нужно сделать древо из всего репозитория. И поэтому перед любым коммитом в группе разработчиков первое это «merge», которое может окончиться (не)известно чем. Поэтому «стандартный протокол» это
1. создать резервную копию
2. если повезет быстренько все что нужно закоммитить или продолжить к 3.
3. восстанавливай резервную копию, выполняй пункт 2
Автору спасибо.
Вообще, проблема мне кажется в двух основных свойствах Кафка. Первое, это бесплатный продукт. Поэтому его commit это вещь совершенно эфемерная. То есть даже если в коде стоит «noop», то с точки зрения Кафка, это приемлемо. Ведь не секрет, что Американская фирма по производству батареек на заре своего существования укладывала в корпус батареек грунт со двора предприятия, и пользуясь колоссальной дешевизной исходного сырья продавала свои изделия за половину стоимости конкурентов.
По сей причине повторяющийся припев писателя, что мол «но ведь это не применимо, там, где речь идет о деньгах вкладчиков» слушается с юмором. Это конечно очень хорошо, что автор это понимает. Но как — то вот это самое понимание с действиями вместе не очень консистентно.
Вторая, если мое очень поверхностное знакомство с Кафкой я запомнил верно, у Кафка есть возможность воспользоваться разными носителями для хранения записей. По умолчанию она воспользуется файловой системой. И тут commit очень сильно зависит от файловой системы, и даже сборки машины, которая её обеспечивает. Но есть возможность и воспользоваться СУБД. Тем самым открывая доступ к хорошо проверенному механизму обеспечения операции commit. Но тогда КАФКА становится ни чем иным, как ширмой для СУБД.
Что касается скорости обработки пакетов, то простейшая extended procedure на с для Microsoft SQL Server с одним CPU Pentium 2.0 и 1 GB памяти поддерживал производительность 60,000 пакетов в секунду.
То есть в принципе статья конечно полезная, автору огромное спасибо. Но умудриться так долго говорить о дубликатах и производительности, не приведя ни одного эксперимента ( а для сравнения их нужно как минимум два ) получается двойственное ощущение богатого материала и отсутствия сути.
Вообще, если взглянуть на Git как на классическую утилиту, то её главный выигрыш это замечательный алгоритм распознавания изменений. То есть если забыть о проэктах и вернуться к рациональному и непредвзятому мышлению удивляющегося и любопытного ребёнка, то Git это идеальное устройство, чтобы сделать копию какого ни — будь гигантского проэкта, потом наложить на его корневую директорию Git repository, после чего опять же скопировать поверх этого самого проэкта тот же самый проэкт, но, допустим, от другого автора. В тот момент, когда последний файл закончит копирование, Git будет готов ответить на запрос, «есть ли разница». Изощренный пользователь может создать ветвление и построить pull request, для наглядности.
Почему «обзывал». Это прибыльное дело. Вы пишете не профессиональные комментарии, не несущие никакой информации, кроме личных выпадов и цитат из рекламных пособий фирмы производителя ПО.
Я не преследую цели сказать хорошее или плохое о той или иной СУБД. Информация о том, что «MySQL ( недавно ) выпустила новые фитчи для репликации, которые сделали её доступной.» является, не прямой, но цитатой из блога производителя ПО MySQL, представителя команды инженеров из базы данных дефектов.
Вообще после глубокого анализа статьи я пришел в выводу, что Uber видимо вернется к Postgress. После глубокого анализа я пришел к выводу, что выбор Postgress не был случайным или результатом hipe. Расчет был холодный, оправданный и похоже худо ли бедно ли, но бизнес был доволен пакетом ПО. Для этого есть объективные причины инженерного характера, которые без Postgress не решить. Моя оценка за 3 года фирма вернуться к Posgress не сможет, из-за возможной потери лица, но больше 5 лет без него прожить не сможет.
Вот такой прогноз.
После того как MySQL отдали InnoDB, коммерческий продут, а Оракл купила MySQL, примерно год — два назад MySQL выпустила новые фитчи для репликации, которые сделали её доступной. Они до сих пор глючат. Я это говорю не для того, чтобы сказать, что MySQL плох или хорош. Ваши утверждения носят характер маркетинговой рекламной кампании. Вам здесь не место. Занимайтесь этими глупостями в статьях, за которые Ваша фирма платит.
И получается то, что у меня творится на web клиенте почты. Которая то повиснет, то не готова выполнять какие — то запросы, после первого запроса. Что же… выполняешь запрос во второй — третий — иногда четвертый раз. По мере того, как их «резиновая» виртуальная машина прогревает под мои запросы каши, они начинают работать.
И получается что пропустив await, его совсем даже не пропустили, а просто передали в руки конечного пользователя. Зато, я почти уверен, все показатели performance dashboard у разработчика пакета ПО зашкаливают.
***
Экий Вы п-п-п-п-простачек, от английского слова «новичок».
С такими п-п-п-простачками заикой стать можно. У компании Microsoft в контракте с пользователем записан «indemnification clause». Ищите перевод.
Господи, что делать с дилетантами. Они же все и всех убьют и скажут, что действовали во благо человечества. Чем они успешно и занимаются по всему миру.
Взять эталон индустрии разработки ПО. Microsoft SQL Server — физическая репликация ( mirroring ) появилась только с Service Pack 1 SQL Server 2008, то есть в 2010-м, мульти — узловая физическая репликация с доступом для чтения резервной копии в версии 2012, ошибки, которые лишали её возможности нормально работать поправили только в SP2, выпущенного 12-го Июля 2016-го года.
Сравнивая поддержкой репликации СУБД Postgres, мне кажется критика «хайповой библиотечки, которая только » не только не обоснована, но совершенно не отражает реальность.
Поддерживает кластер пользуясь инфраструктурой PKI, не требуя Windows Active Directory.
Бугая сзади нету, фотогеничный мальчик.
— и как это поможет исправить переход на MySQL?
Если эту фразу интерпретировать, как «Ну Uber сами дураки», то можно тушить свечи. А так… Общее ощущение что молодые ребята вкалывают, принимают волевые решения. Удачи.
Что до смены версий, разворачивать репликацию для перехода на новую версию это конечно один из подходов, но сказать чтобы это было интересно я не могу. Развертка триггеров дело вполне по плечу среднему разработчику, и сделать скрипт для перехода на обновленную версию дело не сложное. Видимо были какие — то другие приоритеты. Может им кто — то за перехода на MySQL обещал грант подкинуть на разработку робота — водителя, или помочь замять дело с недавней гибелью человека.
Постгрес как база лучше чем MySQL. Это однозначно. И кластеред индекс у неё есть. Автор лукавит. Это создаваемая по умолчанию секвенция строк. Выход на неё по бинарному древу поиска там по — моему с 7-й версии. В общем улучшение репликации пожалуй существенная вещь, но сказать, чтобы она была решающей трудно.
У Вас иллюзия с лазерным мечиком, а не интеллект.
По остальному, циско здесь в США, специально для таких вот приставок и прочего ширпотреба, создал отдельные бренды, которые в витринах под видом дочерних компаний, но на самом деле делается из комплектующих второго и третьего сорта ( которые летят ОТК «в пределах» ). Тут дело в наклейках. Ну а глючит у всех.
Что Гит не может вообще, это сделать древо из изменения имени одного файла. Ему нужно сделать древо из всего репозитория. И поэтому перед любым коммитом в группе разработчиков первое это «merge», которое может окончиться (не)известно чем. Поэтому «стандартный протокол» это
1. создать резервную копию
2. если повезет быстренько все что нужно закоммитить или продолжить к 3.
3. восстанавливай резервную копию, выполняй пункт 2