Поделюсь своей историей, опытом работы с PLC. Где то в конце 200X прикупил я себе спутниковый ресивер DreamBox, для просмотра через пиратские раздачи ключей у него выход в инет только Ethernet. Роутер был в коридоре на шкафу и все другие устройства подключались по WIFI. Тянуть витую пару по плинтусам - не вариант. Будучи в командировке увидел в торговом центре PowerLine Kit от компании Belkin (3 адаптера 100Мбит по цене, если правильно помню, около 60 EUR). Для моих целей это вполне подходило. Подключил 2 и успокоился. Где то через полгода один "сдох" (возможно при скачке напряжения), подключил оставшийся третий и "на дурака" написал e-mail на производителя типа "гарантия год, а вот не работает...". Тех спецы производителя позадавали мне в переписке разные вопросы, я честно отвечал, после чего отписали, что передали информацию в отдел продаж. И вот через месяц почтой получил посылку с новым адаптером, фирменной футболкой и письмом с извинениями. После чего эти адаптеры я еще лет 5 использовал...
:-) Имелось в виду примерно следующее... Как пример. У вас счет в банке и вы хотите иметь наличные. Подходите к банкомату и снимаете необходимую сумму. Ровно так же работает смарт кошелек. Вставляете карту в банкомат/терминал и переводите нужную вам сумму со счета в банке на свой кошелек. Все... Наличные у вас в кошельке и безналичные у вас в "кошельке" на карте (доступная сумма кошелька хранится именно в памяти карты).
Ну как бы тут 2 фактора "играют"... Когда ваши финансы "лежат" в банке (он ими "распоряжается") - вы имеете обычно % дохода от них (ну или кешбек за операции), а когда они "уже ушли из банка на ваш смарт кошелек" банк к ним не имеет отношения (они ваши аналогично наличным) и "защита" от потери и кражи вашего кошелька - ваша проблема.
"Усиление контроля" (особенно на гос.уровне) = отсутствие альтернатив и выбора для конечного потребителя + более высокие расходы для конечного потребителя. Понятно что в первую очередь поставщик любой услуги интересуется только собственной выгодой, и чем не понятнее это для конечного потребителя (который "платит за все") тем лучше для поставщика/продавца. Для государства, с его силовыми механизмами контроля и принуждения внутри страны (а это основные гос. механизмы), вводить безальтернативные решения (в области финансов в первую очередь) еще проще. Если говорить о "технической стороне", в чем смысл ограничения на один счет или аутентификацию клиента строго по номеру телефона? Технически нет проблем использовать одним "клиентом" множества счетов или аутентификацией по цифровым сертификатам. На "уровне" процессингового софта проблем то нет. Что касается смарт карт "кошельков" (работающих в offline режиме) их применение и сейчас довольно широкое, в основном правда как "транспортные" карты, там где требуется высокая скорость обработки безналичной операции и экономия на бесперебойную инфраструктуру обеспечения постоянной online связи. Хранят они в основном небольшие суммы финансовых средств, чтобы в случае потери/краже минимизировать финансовые потери клиента (что в принципе равнозначно кошельку с наличными).
В текущих условиях и тенденциях "цифровой рубль" - очередная попытка государства усиления контроля и управления (в части доступа к финансовым операциям) граждан и организаций, не более того. Какого либо преобладания преимуществ (среди уже существующих безналичных расчетов) пока не наблюдается. Как перспектива заявляются offline операции - но таковые были ранее реализованы в смарт карточных кошельках еще в начале 2000-х и с развитием постоянного Online доступа не выдержали конкуренции с другими типами носителей (Online смарт карт).
Для севера БД, что утилизация CPU "в потолок", что дисковых метрик "в предел" - однозначно проблемы производительности (времени ответа на запрос) в случае "непредусмотренных" всплесков нагрузки, если конечно же в основном это OLTP нагрузка на БД...
ввод данных пользователя, проверка уникальности email - и зачем тут "проверка уникальности email"? Или "только email" в вашей технологии может служить идентификатором (логином) пользователя? По вашей же схеме это не так.... В чем необходимость уникальности e-mail при регистрации?
"SOC по модели Managed Security Service Provider (MSSP) подходит компаниям, стремящимся найти готовое решение с предсказуемым бюджетом." - звучит смешно... :-) С учетом что (как и любая другая "подписка") "завтра" "вдруг" станет на 30% дороже... :-)
"Моя зона ответственности СУБД" - звучит примерно как "с моей стороны пули вылетели, ищите проблемы на своей стороне!" :-) Если понятие "зона ответственности СУБД" у вас заканчивается на "установке параметров БД" - то да, "ничего не менял" = "пули вылетели, ищите не своей стороне".... :-)
:-) Тема то актуальная, но.... "Анализ производительности СУБД" (даже без статистики) интересен "для конкретных условий работы". Условий этих десятки тысяч (начиная от характеристик "железа" х "параметры БД" х "различные профили нагрузки от приложения" х "параметры прикладного софта"). Производительность БД в отрыве от прикладного приложения может учесть только первые два фактора и не факт что максимальная производительность полученная при их оптимизации будет соответствовать максимальной прикладной производительности системы "в целом" (а именно это в большинстве случаев и интересно) + на это накладывается что бизнесу то интересно "минимизация TCO" при допустимо низком % отказа в обслуживании - а это еще более сложно рассчитать...
:-) USB нужен, чтобы хранить там "большой список" ресурсов для обхода блокировки или "большой объем" файлов софта роутера для vpn клиентов/серверов , DPI спуферов и т.п., поскольку объем флеш памяти у роутера "не резиновый"....
В принципе железка нормальная, но лучше "заранее" брать что-то с USB3 портом... Мало ли что придется использовать потом на роутере... Если "дешево и сердито" то например Netis N6. MT7621 256MB RAM 16GB flash + USB3
:-) Ну как бы "без роутера" нет частных сетей... Запретить роутеры физически сложно (примерно как физически интернет, ну или как радио в ссср)... Полностью запретить соединения с любыми зарубежными серверами - так же достаточно проблематично (хотя более реально, грядущий чебурнет)... :-)
:-) Потерь для кого? Если "для разработчика" - то "чем дольше" будут появляться новые требования к ПО - тем больше "денег срубишь!", т.е. он не заинтересован делать "один раз и навсегда". Аналогично "для внедренцев" и devops и аналитиков. Ну а пользователи - "пусть страдают", как и бизнес который "дальше собственного носа не видит"... Как то так...
:-) Это я к тому что "проще" - совсем не значит "оптимальнее"... Вы можете использовать сотни микросервисов на нескольких десятках серверов (поставщики ресурсов, разработчики и devops-ы этому будут только рады), хотя возможно вам вам вполне достаточно одного "монолита" на 3 серверах... Каждое оптимальное решение требует аналитики, оценки, проработки и тестирования под ваши конкретные требования и условия, но можно и "по agile" - "раз, два и в продакшен, а там видно будет...."
:-) Т.е. просто не разрешать приложению работать в фоне, не решение?
:-) Для спутникового ресивера для получения пиратских ключей раскодировки каналов вполне хватало... Думаю что больше 10Мб точно было....
Поделюсь своей историей, опытом работы с PLC. Где то в конце 200X прикупил я себе спутниковый ресивер DreamBox, для просмотра через пиратские раздачи ключей у него выход в инет только Ethernet. Роутер был в коридоре на шкафу и все другие устройства подключались по WIFI. Тянуть витую пару по плинтусам - не вариант. Будучи в командировке увидел в торговом центре PowerLine Kit от компании Belkin (3 адаптера 100Мбит по цене, если правильно помню, около 60 EUR). Для моих целей это вполне подходило. Подключил 2 и успокоился. Где то через полгода один "сдох" (возможно при скачке напряжения), подключил оставшийся третий и "на дурака" написал e-mail на производителя типа "гарантия год, а вот не работает...". Тех спецы производителя позадавали мне в переписке разные вопросы, я честно отвечал, после чего отписали, что передали информацию в отдел продаж. И вот через месяц почтой получил посылку с новым адаптером, фирменной футболкой и письмом с извинениями. После чего эти адаптеры я еще лет 5 использовал...
:-) Имелось в виду примерно следующее... Как пример.
У вас счет в банке и вы хотите иметь наличные. Подходите к банкомату и снимаете необходимую сумму. Ровно так же работает смарт кошелек. Вставляете карту в банкомат/терминал и переводите нужную вам сумму со счета в банке на свой кошелек. Все... Наличные у вас в кошельке и безналичные у вас в "кошельке" на карте (доступная сумма кошелька хранится именно в памяти карты).
Ну как бы тут 2 фактора "играют"...
Когда ваши финансы "лежат" в банке (он ими "распоряжается") - вы имеете обычно % дохода от них (ну или кешбек за операции), а когда они "уже ушли из банка на ваш смарт кошелек" банк к ним не имеет отношения (они ваши аналогично наличным) и "защита" от потери и кражи вашего кошелька - ваша проблема.
"Усиление контроля" (особенно на гос.уровне) = отсутствие альтернатив и выбора для конечного потребителя + более высокие расходы для конечного потребителя. Понятно что в первую очередь поставщик любой услуги интересуется только собственной выгодой, и чем не понятнее это для конечного потребителя (который "платит за все") тем лучше для поставщика/продавца. Для государства, с его силовыми механизмами контроля и принуждения внутри страны (а это основные гос. механизмы), вводить безальтернативные решения (в области финансов в первую очередь) еще проще.
Если говорить о "технической стороне", в чем смысл ограничения на один счет или аутентификацию клиента строго по номеру телефона? Технически нет проблем использовать одним "клиентом" множества счетов или аутентификацией по цифровым сертификатам. На "уровне" процессингового софта проблем то нет.
Что касается смарт карт "кошельков" (работающих в offline режиме) их применение и сейчас довольно широкое, в основном правда как "транспортные" карты, там где требуется высокая скорость обработки безналичной операции и экономия на бесперебойную инфраструктуру обеспечения постоянной online связи. Хранят они в основном небольшие суммы финансовых средств, чтобы в случае потери/краже минимизировать финансовые потери клиента (что в принципе равнозначно кошельку с наличными).
В текущих условиях и тенденциях "цифровой рубль" - очередная попытка государства усиления контроля и управления (в части доступа к финансовым операциям) граждан и организаций, не более того.
Какого либо преобладания преимуществ (среди уже существующих безналичных расчетов) пока не наблюдается. Как перспектива заявляются offline операции - но таковые были ранее реализованы в смарт карточных кошельках еще в начале 2000-х и с развитием постоянного Online доступа не выдержали конкуренции с другими типами носителей (Online смарт карт).
Для севера БД, что утилизация CPU "в потолок", что дисковых метрик "в предел" - однозначно проблемы производительности (времени ответа на запрос) в случае "непредусмотренных" всплесков нагрузки, если конечно же в основном это OLTP нагрузка на БД...
ввод данных пользователя, проверка уникальности email - и зачем тут "проверка уникальности email"? Или "только email" в вашей технологии может служить идентификатором (логином) пользователя? По вашей же схеме это не так.... В чем необходимость уникальности e-mail при регистрации?
:-)
— Самуил Маркович, Вы сильный, Вы справитесь!
— Яша, я — умный, я даже не возьмусь!
"SOC по модели Managed Security Service Provider (MSSP) подходит компаниям, стремящимся найти готовое решение с предсказуемым бюджетом." - звучит смешно... :-)
С учетом что (как и любая другая "подписка") "завтра" "вдруг" станет на 30% дороже... :-)
"Моя зона ответственности СУБД" - звучит примерно как "с моей стороны пули вылетели, ищите проблемы на своей стороне!" :-)
Если понятие "зона ответственности СУБД" у вас заканчивается на "установке параметров БД" - то да, "ничего не менял" = "пули вылетели, ищите не своей стороне".... :-)
:-) Тема то актуальная, но....
"Анализ производительности СУБД" (даже без статистики) интересен "для конкретных условий работы". Условий этих десятки тысяч (начиная от характеристик "железа" х "параметры БД" х "различные профили нагрузки от приложения" х "параметры прикладного софта"). Производительность БД в отрыве от прикладного приложения может учесть только первые два фактора и не факт что максимальная производительность полученная при их оптимизации будет соответствовать максимальной прикладной производительности системы "в целом" (а именно это в большинстве случаев и интересно) + на это накладывается что бизнесу то интересно "минимизация TCO" при допустимо низком % отказа в обслуживании - а это еще более сложно рассчитать...
:-) Пока еще мегабайты... + мегабайт рекламных... Но это пока... Роутеры с несколькими vpn клиентами еще недавно были массово не востребованы... :-)
:-) USB нужен, чтобы хранить там "большой список" ресурсов для обхода блокировки или "большой объем" файлов софта роутера для vpn клиентов/серверов , DPI спуферов и т.п., поскольку объем флеш памяти у роутера "не резиновый"....
В принципе железка нормальная, но лучше "заранее" брать что-то с USB3 портом... Мало ли что придется использовать потом на роутере...
Если "дешево и сердито" то например Netis N6. MT7621 256MB RAM 16GB flash + USB3
:-) Ну как бы "без роутера" нет частных сетей... Запретить роутеры физически сложно (примерно как физически интернет, ну или как радио в ссср)... Полностью запретить соединения с любыми зарубежными серверами - так же достаточно проблематично (хотя более реально, грядущий чебурнет)... :-)
Берешь "роутер без VPN" и "превращаешь" его в "роутер с VPN и обходом блокировок".... Все "удовольствие" < 4000 руб... :-)
:-) Потерь для кого? Если "для разработчика" - то "чем дольше" будут появляться новые требования к ПО - тем больше "денег срубишь!", т.е. он не заинтересован делать "один раз и навсегда". Аналогично "для внедренцев" и devops и аналитиков. Ну а пользователи - "пусть страдают", как и бизнес который "дальше собственного носа не видит"... Как то так...
:-) Это я к тому что "проще" - совсем не значит "оптимальнее"... Вы можете использовать сотни микросервисов на нескольких десятках серверов (поставщики ресурсов, разработчики и devops-ы этому будут только рады), хотя возможно вам вам вполне достаточно одного "монолита" на 3 серверах... Каждое оптимальное решение требует аналитики, оценки, проработки и тестирования под ваши конкретные требования и условия, но можно и "по agile" - "раз, два и в продакшен, а там видно будет...."