Начинать аргументацию с совершеннейшей подмены терминов и тезисов, Играть в пинг-понг вопросами, вместо фактических аргументов, и использовать прочие старые добрые демагогические приемы это весьма похвально.
Штош. Используем ваши же методы.
Напоминаю, что мой комментарий посвящен распределенным БД (не просто любым БД)
По поводу самого главного. Все остальное вообще не важно.
Расскажите, на основе каких таких данных (эмпирических, теоретических, гностических и т.д.) вы пришли к выводу, что распределенные БД возникли как реакция на появление интернета и отсутствие мистических мощностей. Меня интересует прямо очень сильно.
Обтатите внимание на раздел "Общие сведения" там освещены все основные моменты.
Единые интерфейсы это DDL и DML. Все RDBMS поддерживают данный стандарт. По этому, что называется модным словом "из коробки" любая гетерогенная среда относительно легко может быть взаимно интегрирована. На локальном уровне, диалекты могут отличаться, но общий стандарт остается. Oracle, MS SQL, MySQL, Posgres, Access (из настольных) - это разные RDBMS, но любой пользовтель знакомый с SQL сможет манипулировать данными ОДИНАКОВО.
Все перечисленные мной выше RDBMS (Oracle, MS SQL, MySQL, Posgres, Access), как я полагаю для вас олдскул. Так вот. Перечислите какие из них по вашему не могут быть распределенными.
"Почему вы считаете, что KV-хранилища не могут обеспечивать ACID?" А почему вы считаете что могут? Какие, например у redis внутренние:
поддерживаемые атомарные типы данных
механизмы описания схемы данных
механизмы обеспечения целостности (домены типов, составные уникальные ключи, внешние ключи) про остальные страшные штуки (типа механизмов отслеживания роста экстентов и разряженности\плотности записи данных) я даже заикаться не буду.
"Почему вы считаете, что ACID - неотъемлемое свойство БД?" Наверное потому, что речь о распределенной БД? Вы же рассуждаете о надежных, отказоустойчивых, непротиворечивых и защищенных БД? Или речь идет про курсовую на Paradox?
Я совершенно не против новых велосипедов. Новые инструменты это всегда хорошо. Это альтернатива. Хотя бы для того, чтобы мозги у разработчика начали думать в других направлениях. И не костенели. Вопрос всегда в адекватности применения. Нужно хорошо знать текущую мат базу и разумно применять рационализаторские решения. Там, где действительно надо. Не поддаваться юношеской неискушенности и максимализму (как сейчас в отрасли, т.к. объективно она стала более детской со всеми же детскими "болячками")
Боже мой! Автор. Ну хоть бы открыл вики перед написанием такой ереси, как: "Но когда появился интернет, мощностей стало немножко не хватать, и как следствие – понадобились новые подходы для хранения данных. Так появились распределенные базы данных, живущие сразу на многих серверах."
База даных это связная и неделимая структура возможная ТОЛЬКО при наличии ФОРМАЛЬНЫХ связей обеспечиваюших целостность и непротиворечивость этих данных. Такое возможно ТОЛЬКО в рамках модели РЕЛЯЦИОННЫХ баз данных обеспечиваюших ЕДИНЫЙ ИНТЕРФЕЙС прикладного уровня. База данных это не набор файлов, а набор правил в соответствии и теорией. Файлы это один из уровней ФИЗИЧЕСКОЙ модели управления БАЗАМИ ДАННЫХ в рамках RDBMS. По этому физическое размещение и структура ни коим образом не относится к самим БАЗАМ данных и ими не является.
Все ваши key/value и тд массивы не являются БАЗАМИ АННЫХ. Они не обеспечивают базовые принципы ACID. Их и интерфейсов доступа к ним - зоопарк. И по этому для поддержки производительности этих "модных" систем каждый раз нужны разные костыли.
Мы сейчас вошли в период, когда на этих костылях написаны (и продолжают тиражироваться) очень чувствительные к надежности отрасли и вот вот должен выполнится второй закон Вейнберга.
Если это статья для общего развития и популяризации, то очень странно, что срвершенно нет даже простейшей "на пальцах" расшифровки термина "ПИД-регулятор".
Я, например, как не знал этого до статьи, так не знаю после. Я понимаю свойства двнной сущности в результате прочтения, но что это физически - тайна
Давно не встречал такой полноты раскрытия свих комплексов и субъективных представлений, а также их беззастенчивой экстраполяции на "всё" сообщество. Видимо я попал в ваше (и вам похожих) "больное место" и вы почувствовали что у вас отбирают "любимую игрушку", а именно - выразить "свое экспертное мнение". благо для этого нужно всего лишь написать пару слов вида: "все неправильно", "так никто не делает" и тд и тп. ведь в интернете никто не узнает, что ты кот. практически всегда, когда просишь такого "эксперта" показать свой код или готовое устройство или нарисовать принципиальную схему они либо сливаются, либо лепят фееричные отмазки.
мой комментарий собрал минусы именно таких "жуспертов" и я рад этому.
критика хороша, когда она по адресу. например, если кто то открыл производство и продает за деньги, позиционируя себя как профи. В данном случае нужна не критика, а дружеский совет, например. А ещё лучше - пример реализации (хотя бы в виде картинки) более удачного варианта (по вашему мнению). А словами трындеть, какие все вкруг супер специалисты все умеют и любят. Вот например, третий день ищу красивые накладные розетки и распред шкафы. но хер. везде одно и то же. убожество квадратно-колхозное. зато - промдизайн. шляпа одним словом.
Отлично! Щас набегут снобы от схемотехники и "папулярно разжуют", что правильно - надо разводить не так, а по другому, и вообще нужен обязательно пром дизайн и тд и тп. Ну их. Работает. Приносит пользу. И это главное
3д печать только для прототипов. К сожалению в доме не могу поставить установку литья под давлением. Да и цены на оборудование и расходники не дл меня. Максимум научился лить из 2 компонентного компаунда типа Smooth Cast. предварительно сделав силиконовую форму. Но. Это тоже дорого. Это тоже техпроцесс. И его нужно осваивать (у иеня идея фикс слинковать из ииеющихся в быту элементов самосборное устройство. доступное в сборке, ремонте, да чтоб было эстетически приемлемое). к тому же, по опыту литья этими продуктами. тонкостенное ими лить сложно. это свойства материала. особенно там, где нужны усилия (защелки). Хочется найти относительно недорогой, эстетически приемлимый и доступный корпус, чтобы под него развести девайс.
для коммутации нагрузки (тэны, двигатели и тд) ящик в технич комнате. Там использую одномодульные контакторы от китайцев на 25А вот ими можно управлять через мини э/м реле каскадом. Они в принципе слеланы просто (каждый девайс разбираю и смотрю что там. можно ли его использовать, какая элкментная база и тд).
хороший запас по мощности это и надежность и безопасность.
по моему опыту использования датчика потока он очень капризный. небольшие изменения вообще не ловит. надо что то, типа счетчика воды, по чувсчюствительности. и наверное нужна доп емкость, а ее объем надо считать из среднего расхода и среднего притока воды. чтоб хватало.
ну и конечно - никаких сторонних прошивок, очень не хочется, чтобы управлене жизненно важными элементами быта шло через эти ваши интернеты и китайские облака.
а вообще не совсем пончтна задача. откуда прступает вода в стагцию? у меня, например, станция раздает воду из емкости. контроль сухого хода простой поплавок как только нижняя допустимая граница пройдена насос просто откл.
все остальное дополнительные контуры. дистанционное отключение, уровень в баке и тд и тп.
и да... потихоньку прихожу к своим схемотехнич решениям. благо есть где заказать pcb. Спасибо китайцам. У нас бесполезно. Что новосиб, что Питер.. ценник ппц и микропартиями не заморачиваются. никакого желания с ними работать нет.
зсморачиваюсь тоже девайсами. китайские реле в принципе хороши. кроме самих электромагнитных реле. ими можно замыкать разве что мелкую нагрузку. склонны к залипанию. по этому для себя сделал патч плату (по контактам штатных реле) но вместо Э/М схема с симистором и опторазвязкой. BTA41-800 входит на ура + до развязка. единственное, только 1 режим N/O. В остальном одни плюсы.
в чем экономия? дешёвый orange pi 1гб и 4 ядра спокойно тянет все базовое по. и mqtt и web и mysql и тл и тп. одноплатники тянут все. у вас же не сотни запросов в секунду. а если нагрузка подеялась, штош, купи второй одноплатник и разнеси сервисы. цена вопроса не килобаксы, а какие то пару тысяч рублей
увы. там маркетинговый текст. не технический. ни одного технического термина. все сплошь стеки, управленческие шаблоны и тому подобное словоблудие. ещё раз повторюсь. для инфосистем подобного типа фронт имеет второстепенное значение. Первичен быстро и качественно работающий бэк, жующий гигантские объемы данных и при этом быстро отдающий данные и фронту и клиентам.
Это пока. Уверен, что в момент запуска предыдущей версии тоже не было нареканий. Ведь все списывалось на наличие и отработку базового функционала (большинство доп бизнес процессов переводятся на ручной режим.. потерпите немного, сейчас мы тут основное допилим) . Все начинается после полноценной сдачи в работу и поддержку. Когда подписаны бумаги, что все слелано и отговорок уже не может быть. А бизнес не ждёт. У него свой техдолг. Первое время как то можно отпинываться, но через пол года, год станет невозможно. Придется начинать выполнять их задачи. А объёмы данных растут, а интеграций всё больше. И начинается самый увлекательный процесс - костылегенерация. Это мы ещё не знаем, как и кто писал самое основное - бэк, как и кем разрабатывалась семантическая модель данных (ведь старые то ушли... или их ушли.. это вопросы и тут только ваша версия). если с кривым вебом, двузвенкой (давно научились справляться, путем кластера терминальных серверов, для узких каналрв и тд) можно жить и прогнозировать, то с кривым бэком, кривой структурой БД и невозможностью ее лёгкой адаптации (потому что писали как умели, а не как надо) вы долго не протянете. совершенно не важно на чем у вас фронт написан. это вкусовщина и особой роли не играет. хоть в Excel. всегда важны данные. их непротиворечивость, скорость отклика на мутации и чтение. По этому. Вы конечно проделали работу за деньги, но радоваться пока не чему. Нужна наработка на отказ. Я более чем, уверен, что когда все у вас начнёт безумно тормозить и сыпаться (а это будет. это объективная реальность. меняются задачи и структура данных) вы не придете и не напишите здесь объективный отчет по этому поводу.
ужоснах.
для примера mvp статьи давно придумали cms. ничего думать не надо.
sms сейчас уже за мессенджер не считаются? а ведь буква m кагбе намекает.
Однакось.
Начинать аргументацию с совершеннейшей подмены терминов и тезисов,
Играть в пинг-понг вопросами, вместо фактических аргументов,
и использовать прочие старые добрые демагогические приемы
это весьма похвально.
Штош. Используем ваши же методы.
Напоминаю, что мой комментарий посвящен распределенным БД (не просто любым БД)
По поводу самого главного. Все остальное вообще не важно.
Расскажите, на основе каких таких данных (эмпирических, теоретических, гностических и т.д.)
вы пришли к выводу, что распределенные БД возникли как
реакция на появление интернета и отсутствие мистических мощностей.
Меня интересует прямо очень сильно.
по поводу вики
я понимаю, что вам лень смотреть, но вот
https://ru.wikipedia.org/wiki/Распределённая_база_данных
Обтатите внимание на раздел "Общие сведения" там освещены все основные моменты.
Единые интерфейсы это DDL и DML. Все RDBMS поддерживают данный стандарт. По этому, что называется
модным словом "из коробки" любая гетерогенная среда относительно легко может быть взаимно интегрирована.
На локальном уровне, диалекты могут отличаться, но общий стандарт остается.
Oracle, MS SQL, MySQL, Posgres, Access (из настольных) - это разные RDBMS, но любой пользовтель
знакомый с SQL сможет манипулировать данными ОДИНАКОВО.
Все перечисленные мной выше RDBMS (Oracle, MS SQL, MySQL, Posgres, Access), как я полагаю для вас олдскул. Так вот. Перечислите
какие из них по вашему не могут быть распределенными.
"Почему вы считаете, что KV-хранилища не могут обеспечивать ACID?"
А почему вы считаете что могут?
Какие, например у redis внутренние:
поддерживаемые атомарные типы данных
механизмы описания схемы данных
механизмы обеспечения целостности (домены типов, составные уникальные ключи, внешние ключи) про остальные страшные штуки (типа механизмов отслеживания роста экстентов и разряженности\плотности записи данных) я даже заикаться не буду.
"Почему вы считаете, что ACID - неотъемлемое свойство БД?"
Наверное потому, что речь о распределенной БД?
Вы же рассуждаете о надежных, отказоустойчивых, непротиворечивых и защищенных БД?
Или речь идет про курсовую на Paradox?
Я совершенно не против новых велосипедов. Новые инструменты это всегда хорошо. Это альтернатива.
Хотя бы для того, чтобы мозги у разработчика начали думать в других направлениях. И не костенели.
Вопрос всегда в адекватности применения.
Нужно хорошо знать текущую мат базу и разумно применять рационализаторские решения. Там, где действительно надо.
Не поддаваться юношеской неискушенности и максимализму (как сейчас в отрасли, т.к. объективно она стала более детской со всеми же
детскими "болячками")
Боже мой! Автор. Ну хоть бы открыл вики перед написанием такой ереси, как: "Но когда появился интернет, мощностей стало немножко не хватать, и как следствие – понадобились новые подходы для хранения данных. Так появились распределенные базы данных, живущие сразу на многих серверах."
База даных это связная и неделимая структура возможная ТОЛЬКО при наличии ФОРМАЛЬНЫХ связей обеспечиваюших целостность и непротиворечивость этих данных. Такое возможно ТОЛЬКО в рамках модели РЕЛЯЦИОННЫХ баз данных обеспечиваюших ЕДИНЫЙ ИНТЕРФЕЙС прикладного уровня. База данных это не набор файлов, а набор правил в соответствии и теорией. Файлы это один из уровней ФИЗИЧЕСКОЙ модели управления БАЗАМИ ДАННЫХ в рамках RDBMS. По этому физическое размещение и структура ни коим образом не относится к самим БАЗАМ данных и ими не является.
Все ваши key/value и тд массивы не являются БАЗАМИ АННЫХ. Они не обеспечивают базовые принципы ACID. Их и интерфейсов доступа к ним - зоопарк. И по этому для поддержки производительности этих "модных" систем каждый раз нужны разные костыли.
Мы сейчас вошли в период, когда на этих костылях написаны (и продолжают тиражироваться) очень чувствительные к надежности отрасли и вот вот должен выполнится второй закон Вейнберга.
Удачи
Если это статья для общего развития и популяризации, то очень странно, что срвершенно нет даже простейшей "на пальцах" расшифровки термина "ПИД-регулятор".
Я, например, как не знал этого до статьи, так не знаю после. Я понимаю свойства двнной сущности в результате прочтения, но что это физически - тайна
вот тут вы как раз и ошибаетесь. на уровне подсознания она и оседает. это на уровне сознания у вас фильтр.
а есть такая профессия - журналист? о чем она? если вместо журналистов будет просто констатация фактов. будет лучше или нет?
Давно не встречал такой полноты раскрытия свих комплексов и субъективных представлений, а также их беззастенчивой экстраполяции на "всё" сообщество. Видимо я попал в ваше (и вам похожих) "больное место" и вы почувствовали что у вас отбирают "любимую игрушку", а именно - выразить "свое экспертное мнение". благо для этого нужно всего лишь написать пару слов вида: "все неправильно", "так никто не делает" и тд и тп. ведь в интернете никто не узнает, что ты кот. практически всегда, когда просишь такого "эксперта" показать свой код или готовое устройство или нарисовать принципиальную схему они либо сливаются, либо лепят фееричные отмазки.
мой комментарий собрал минусы именно таких "жуспертов" и я рад этому.
критика хороша, когда она по адресу. например, если кто то открыл производство и продает за деньги, позиционируя себя как профи. В данном случае нужна не критика, а дружеский совет, например. А ещё лучше - пример реализации (хотя бы в виде картинки) более удачного варианта (по вашему мнению). А словами трындеть, какие все вкруг супер специалисты все умеют и любят. Вот например, третий день ищу красивые накладные розетки и распред шкафы. но хер. везде одно и то же. убожество квадратно-колхозное. зато - промдизайн. шляпа одним словом.
Отлично! Щас набегут снобы от схемотехники и "папулярно разжуют", что правильно - надо разводить не так, а по другому, и вообще нужен обязательно пром дизайн и тд и тп. Ну их. Работает. Приносит пользу. И это главное
3д печать только для прототипов. К сожалению в доме не могу поставить установку литья под давлением. Да и цены на оборудование и расходники не дл меня. Максимум научился лить из 2 компонентного компаунда типа Smooth Cast. предварительно сделав силиконовую форму. Но. Это тоже дорого. Это тоже техпроцесс. И его нужно осваивать (у иеня идея фикс слинковать из ииеющихся в быту элементов самосборное устройство. доступное в сборке, ремонте, да чтоб было эстетически приемлемое). к тому же, по опыту литья этими продуктами. тонкостенное ими лить сложно. это свойства материала. особенно там, где нужны усилия (защелки). Хочется найти относительно недорогой, эстетически приемлимый и доступный корпус, чтобы под него развести девайс.
я задолбался искать корпуса для своих поделок. как вы их находите?
что это за графоманство?
для коммутации нагрузки (тэны, двигатели и тд) ящик в технич комнате. Там использую одномодульные контакторы от китайцев на 25А вот ими можно управлять через мини э/м реле каскадом. Они в принципе слеланы просто (каждый девайс разбираю и смотрю что там. можно ли его использовать, какая элкментная база и тд).
хороший запас по мощности это и надежность и безопасность.
по моему опыту использования датчика потока он очень капризный. небольшие изменения вообще не ловит. надо что то, типа счетчика воды, по чувсчюствительности. и наверное нужна доп емкость, а ее объем надо считать из среднего расхода и среднего притока воды. чтоб хватало.
ну и конечно - никаких сторонних прошивок, очень не хочется, чтобы управлене жизненно важными элементами быта шло через эти ваши интернеты и китайские облака.
а вообще не совсем пончтна задача. откуда прступает вода в стагцию? у меня, например, станция раздает воду из емкости. контроль сухого хода простой поплавок как только нижняя допустимая граница пройдена насос просто откл.
все остальное дополнительные контуры. дистанционное отключение, уровень в баке и тд и тп.
и да... потихоньку прихожу к своим схемотехнич решениям. благо есть где заказать pcb. Спасибо китайцам. У нас бесполезно. Что новосиб, что Питер.. ценник ппц и микропартиями не заморачиваются. никакого желания с ними работать нет.
зсморачиваюсь тоже девайсами. китайские реле в принципе хороши. кроме самих электромагнитных реле. ими можно замыкать разве что мелкую нагрузку. склонны к залипанию. по этому для себя сделал патч плату (по контактам штатных реле) но вместо Э/М схема с симистором и опторазвязкой. BTA41-800 входит на ура + до развязка. единственное, только 1 режим N/O. В остальном одни плюсы.
в чем экономия? дешёвый orange pi 1гб и 4 ядра спокойно тянет все базовое по. и mqtt и web и mysql и тл и тп. одноплатники тянут все. у вас же не сотни запросов в секунду. а если нагрузка подеялась, штош, купи второй одноплатник и разнеси сервисы. цена вопроса не килобаксы, а какие то пару тысяч рублей
увы. там маркетинговый текст. не технический. ни одного технического термина. все сплошь стеки, управленческие шаблоны и тому подобное словоблудие. ещё раз повторюсь. для инфосистем подобного типа фронт имеет второстепенное значение. Первичен быстро и качественно работающий бэк, жующий гигантские объемы данных и при этом быстро отдающий данные и фронту и клиентам.
Это пока. Уверен, что в момент запуска предыдущей версии тоже не было нареканий. Ведь все списывалось на наличие и отработку базового функционала (большинство доп бизнес процессов переводятся на ручной режим.. потерпите немного, сейчас мы тут основное допилим) . Все начинается после полноценной сдачи в работу и поддержку. Когда подписаны бумаги, что все слелано и отговорок уже не может быть. А бизнес не ждёт. У него свой техдолг. Первое время как то можно отпинываться, но через пол года, год станет невозможно. Придется начинать выполнять их задачи. А объёмы данных растут, а интеграций всё больше. И начинается самый увлекательный процесс - костылегенерация. Это мы ещё не знаем, как и кто писал самое основное - бэк, как и кем разрабатывалась семантическая модель данных (ведь старые то ушли... или их ушли.. это вопросы и тут только ваша версия). если с кривым вебом, двузвенкой (давно научились справляться, путем кластера терминальных серверов, для узких каналрв и тд) можно жить и прогнозировать, то с кривым бэком, кривой структурой БД и невозможностью ее лёгкой адаптации (потому что писали как умели, а не как надо) вы долго не протянете. совершенно не важно на чем у вас фронт написан. это вкусовщина и особой роли не играет. хоть в Excel. всегда важны данные. их непротиворечивость, скорость отклика на мутации и чтение. По этому. Вы конечно проделали работу за деньги, но радоваться пока не чему. Нужна наработка на отказ. Я более чем, уверен, что когда все у вас начнёт безумно тормозить и сыпаться (а это будет. это объективная реальность. меняются задачи и структура данных) вы не придете и не напишите здесь объективный отчет по этому поводу.