Ну вообще, проблему качественно разработали и досталось всем. AMD не исключение. Intel просто перегнул палку с оптимизациями. Другое дело, что с OoO сложно что-то сделать в подобных сценариях атак, поскольку есть общий кеш и исполнение кода, из будущего уже в настоящем. Чтобы качественно закрыть все возможности атак, нужно либо предисполнение делать на другом наборе кешей, либо эти кеши как-то особо закрывать, что явно угробит весь профит от данного предисполнения...
В статье поются дифирамбы Out of Order, который стал источником уязвимостей, с которыми крайне сложно бороться, а выключение его на превращало камень в тыкву. Причём проблемными оказывались и ARM и x86. Нужно ли нам в это болото?
а делать правильно
Никто не знает как правильно, поэтому слабые духом делают так же. Процессоры, которые пошли этим же путём, мы знаем, это и Байкалы. Мне кажется второй Байкал от МЦСТ будет лишним для рынка России, не отличающегося масштабами. А SPARC и собственный VLIW вполне хорошие запасные варианты.
И ещё раз. Да, я согласен, что Эльбрус для задач общего назначения странен. И не за счёт VLIW, а за счёт того, что там всё плохо с переключением задач. Как говорилось на какой-то конференции, она там крайне дорога. Я не думаю, что он пойдёт в массы. Скорее в массы пойдёт вполне предсказуемый Байкал, поскольку АРМ-ом и MIPS сейчас никого не удивишь. Эльбрус - это специальные и большие супер машины и числодробительные ускорители, там как кажется его удастся раскрыть. Но нет у нас сейчас даже намёков на интерес к таким машинам. А когда появится МЦСТ уже сдохнет и разложится. Поэтому пытаются найти нишу для архитектуры, с надеждой на светлое будущее.
Китайцы в 90 делали дрянь, сейчас они делают нам почти всё чем мы пользуемся. Чтобы делать хорошо, нужно учиться. А учиться без проб и ошибок не выйдет. Чтобы оригинальная архитектура давала производительность на уровне мировых аналогов, нужно производство и разработку на уровне мировых аналогов. Где это взять, если не развивать самим? Кто даст технологии мирового уровня, какой дебил добровольно отдаст своё конкурентное преимущество в капиталистическом мире. Долго учится, подглядывая у лучших, а потом сразу сделать шедевр, который их всех затмит - такое бывает только в сказках. Совершенство - тяжёлый труд нескольких поколений, когда на старте имеем дрянь, которая со временем становится совершенней. Эльбрус стартовал с высокой базы, и сразу стал не полным дерьмом, а вполне рабочей вещью. Дальше совершенствование, ввод дополнительных блоков, улучшающих подклассы задач, сопроцессоров, и возможно вынос транслятора x86 в отдельный чип, а лучше постепенно от него отказываться в подлинейке моделей. Но это работа на будущее, а пока пользуемся тем, что имеем, и судорожно придумываем, что нам нужно в будущем, чтобы определить приоритеты развития платформы. Просто "сделайте нам как у них, только у вас, и также быстро" это не вектор развития, это констатация его отсутствия.
С одной стороны МЦСТ это де факто - советское НИИ. Т.е. есть объективные проблемы с пониманием того, как работать в нынешних условиях, и желанием работать над продвижением своих продуктов. ОКРы сдаются - и хорошо.
Повеселило. В нынешних условиях это как? Существенная часть продуктов работается по схеме тяп-ляп и в продуктив, и побольше хайпа. Откуда столько негатива к планомерной рутинной работе. Продвигать продукт возможно они и хотят (и нет такого разработчика, который не хотел бы широкого распространения своего детища), но есть объективные проблемы:
Начиная с первого появления живых образцов, вокруг архитектуры клубится негатив со стороны "разбирающейся в теме общественности". Сражаться с ветряными мельницами в виде людей, которым и интелов с армами вполне достаточно - глупо. В МЦСТ явно есть на что потратить деньги без попыток снизить кислотность общественной среды.
Отсутствует образ будущего со стороны государства и "общественности". Что нужно от машины на горизонте 10-15 лет, куда стремиться. На рынке, где архитектура Эльбруса всюду инородна нет смысла заниматься активным продвижением, поскольку на данный момент сам процессор страдает от бича российской действительности, когда нужно уметь и нашим и вашим, и Intel-ом прикинутся и быть не интелом, для всяких спец-контор.
Существует заказчик (как говорят), которого процессор устраивает, так зачем распылять силы на продвижение, если можно их сосредоточить на продукте. Динамика прироста возможностей, у процессора вполне нормальная.
ИМХО, Эльбрус адекватный процессор, с вполне хорошей производительностью. Для разработки топовых процессоров способных тягаться с гигантами нужно ни одно уцелевшее неведомо как советское НИИ, хоть как-то причастное к изготовлению СБИС, а комплекс этих самых НИИ и опытно-производственная база, чтобы не нужно было на Тайване за 100500 регулярно дорожающих денег заказывать опытные образцы для натурных испытаний. Нужна политика партии на развитие своего, а не нынешнее "импортозамещение", где большая часть всего для галочки. Ну и образ будущего, когда все понимают, что мы строим и спланировано движутся к поставленной цели. Необходимость тратить транзисторы на транслятор в процессоре идёт из принятого ещё в 70-тые курса на облегчение цельнодратия с прогрессивных и умных американцев их прогрессивного и умного софта. Мы ж не можем у нас совок и лапки... Ну и для того, чтобы продукт вывести не через 30 лет, а сильно раньше. Когда у нас будет гордость и желание обеспечивать себя ПО, а не тырить или закупать заморское чудо чудесное, в товарных объёмах, тогда и достоинства Эльбруса раскроются, а влияние недостатков будет уменьшено. Хороший пример - Японцы, у которых две тяжёлые машины от фуджика собраны на своём, не так чтобы хайповом, процессоре. На АРМ-е, когда это не было ещё так модно и Спарке, который не особо признан в HPC.
Сколько недостатков у Эльбруса нет, но это последний оригинальный Российский процессор. Только поэтому его стоит тянуть и активно использовать во всяких специальных и закрытых системах. Разучимся делать оригинальные вещи, можно закутываться в простыню и тащится на кладбище, ничего путного в будущем уже сделать не сможем.
БД в моём комментарии, это удобное представление данных для всяких инструментов бизнес аналитики, ну или просто подцепить zeppelin и поиграться с графиками поверх запросов с агрегирующими функциями. Если ничего подобного не предполагается, либо анализ чего бы то ни было будет осуществляется всякими нейроночками, map-reduce и прочей магией, то да, отсутствие БД никто не заметит. Однако я старая больная обезьяна, и в этом месте хотелось бы иметь право на SQL запрос.
ORM сокращает время разработки и делает код понятным не знакомым с SQL людям. Однако, на всех конференциях и во всех видео, базёры, при упоминании ORM-а, начинают страшно меняться в лице и изображать лютую душевную боль. Я сам смотрел на поведение PostgreSQL с человеческими и с ORM запросами. У меня волосы шевелились на всех местах, ибо где было достаточно 1-го запроса, эта гадина пускала в базу 10. Возможно я не умею готовить Алхимию, но что-то мне подсказывает что проблема глубже. ORM вполне может стать проблемой при росте, но это моё субъективное ИМХО ORM-о ненавистника.
На горячем коде ИМХО нужно контролировать запросы и точно понимать, что идёт в БД, чтобы самому или с помощью товарищей суметь покрыться слоем живительных индексов. ORM может творить с запросами чёрное и даже очень искушённые товарищи не смогут дать ума этому монстру.
При построении аналитики Вам придётся обратно номализовывать эту структуру, разбирать её по сущностям и раскладывать по отношениям у РСУБД, в противном случаем придётся руками писать всё то, что SQL умеет уже десятилетия. Вся мощь SQL-я строилась для аналитики и раскрывается на базах нормализованных хотя бы до 3-ё нормальной формы. Тогда с данными работать приятно и интересно.
1. Когда парням придёт время строить по этому хранилищу сочную аналитику, их уныние будет глубже.
2. Кто в здравом уме развесистую схему данных под ORM выставляет под нагрузку, ну кроме хипстеров с их стремлением к чистому коду. Частый код он в приложении хипстеров, а если его суммировать с АДОМ ОРМ-а результирующая будет грязнее сточной канавы.
<Сарказм>А вообще, стоит позавидовать парням, что их сценарий улёгся в данный профиль хранения. Я б наверно пошёл дальше и хранил вообще сущности в файлах, а индексы в memcashd, и вообще вышвырнул этот сторедж. Кому он нужен такой тормозной</Сарказм>. И да, в шутке про файлы только доля шутки. Принять имя файла за ключ, а содержимое за значение, подобрать вменяемую ФС и вложенность директорий, и может неплохо получится. А главное этот стор можно разместить много где и жрёт он не так существенно. Есть много проблем, но всё-таки… Ну это так, мысли вслух.
А почему не завести NAS с множеством zfs пулов и не делать zfs send | ssh backup@nas zfs recv, выбирая пул на NAS по каким-то признакам, например по группе серверов или имени кластера, если их несколько. И потом слать инкрементальные копии между 2-я snapshot-ами: старым (который уже отправлен) и новым (выполненным сейчас) через тот же send/recv. Для целей автоматизации старый, после передачи, можно грохнуть а новый переименовать в старый…
В FreeBSD и OpenBSD есть специальный функционал, для синхронизации состояний соединений, чтобы при передаче трафика между нодами statefull firewall оставался работоспособным. ОЧЕНЬ хочется верить, что здесь подобный механизм, поскольку просто перекачивать кучи говнища из кучи и стеков из экземпляра в экземпляр — верный путь вырастить какое нибудь чудовище в этой чаше Петри…
Биометрия бы вполне спасла, вот только пока терминалы для снятия биометрии не так чтобы везде стоят, главное не у всех дома. Их стоимость достаточно велика, а платформы по связыванию систем аутентификации различных организаций нет, и пока не предвидится. Кроме того, в биометрии тоже идут по пути наименьшего сопротивления и делают только верификацию по лицу, хотя факторов должно быть больше (ну как минимум отпечаток пальца и голос, как максимум ещё чего придумать), для возможности более надёжной аутентификации.
Суррогат вроде Google Auth, Microsoft Auth, Yandex Key — это всего лишь суррогат. На каких то моделях устройств это всё завязывается на биометрию, где-то закрывается пином, что не так чтоб сильно улучшает ситуацию. Плюс, это хоть и хитро сгенерированный, но тоже пароль и передаётся тот пароль в том же канале связи, и может программа от того пароля попасть неведомо куда. В общем по своей сути, это тот же пароль с теми же недостатками, хотя в немного подправленном виде.
А вообще, в идеале аутентификация с применением нескольких биометрических данных (в зависимости от серьёзности системы или операции до нескольких одновременно), должна проходить вне основного канала передачи данных через систему посредник. Но опять таки, сдесь нужно думать о схеме работы такой системы, защиты её от предприимчивых людей во власти и за её пределами и обеспечивать массовость и вездесущесть терминалов этой системы, что явно не входит в какие-либо планы.
Та же ситуация с адресом электронной почты — большинство используют email на бесплатных сервисах. Государству стоило бы обеспокоиться созданием специальной почтовый службы для госуслуг и банков, где почтовый адрес был бы привязан с конкретному гражданину, а вероятность его увода была бы исключена.
Это мысль в правильном направлении, но с малым горизонтом. На самом деле имеется пара огромных проблем:
Идентификации и аутентификации конкретного гражданина. Поскольку системы оперируют учётными данными а они напрямую не связаны с людьми а представляют собой всего лишь имя и некий секрет (пароль). То есть нет простого способа не дать завести УЗ на Ивана Ивановича Ивану Петровичу. Вернее можно заводить учётки по паспортам, но вот как проконтролировать, что логин-пароль используются владельцем паспорта, не ясно. А при этом данные системы должны привязываться к человеку а не к логину и паролю, которые могут быть уведены или иными способами скомпрометированы.
Налаживания канала связи с гражданином, а не с абонентским устройством. Та же беда что и в первом пункте, устройство не всегда однозначно находится у конкретного гражданина.
Из этих бед, а точнее из попыток решения их по-быстрому, путём наименьшего сопротивления, и рождается использование почты пользователя, поскольку это самый простой способ его идентификации (попробуйте придумать всем уникальные логины, которые можно запомнить, а почта это сама как-то решает) и связи с ним, и СМС как второй фактор аутентификации и канал оперативного оповещения. Я не думаю что нам нужна гос. почта (ну иная чем она есть на гос. услугах, когда всякие ФНС-ы шлют тебе всякие письма счастья) и гос. СМС-ки. Нам нужна стройная система решающая вышеперечисленные задачи. А пока эти задачи (а они вообще стоят перед всеми этими комитетами цифровизации и иными электронными государствами??!...) не будут решены, к сожалению СМС-ки и почта самое малое из зол. В конце концов, от спец. почты придётся хранить спец пароль… а с хранением паролей у народа ситуация сильно хуже чем с вдумчивым чтением СМС-ок…
И да, для параноиков есть ЭЦП, которая даёт чуть большую защиту, чем просто авторизация по СМС-кам, по крайней мере теоретически.
Ну рядовой мститель к органам за этой инфой не пойдёт, поскольку есть вариант не иллюзорно вляпаться в доброту тех же самых органов. Потом не откупишься ни чем. А тем кому таким образом сливается инфа, далеко не каждый рядовой гражданин интересен. Да и у органов вряд ли каждый день на каждом столе по подшивке СМС-ок за предыдущий день. Во-первых, где они возьмут столько бумаги. Во-вторых, кто это будет читать в таких количествах. В-третьих, если у каждого была бы эта инфа, народ бы уже плотно сидел, или откупался. Поэтому органы должны быть специальными, а следовательно попасть в них может не каждый а вылететь любой. Поэтому с кем попало делится не будут и на контакт тоже идти вряд ли будут. Поэтому данный вариант выглядит кисло…
Если в данном месте принято удостоверять мою личность, значит она должна быть удостоверена надёжно. На сколько мне помнится, вся проблема с ЭЦП связана с тем, что там где нужно принимать паспорта, принимали бумажку с надписью «Это Вася, мамой клянусь», и в результате у Васи из реальной жизни начинались проблемы с отчётностью, кредитами и прочим. Я вот не хочу проснутся и узнать, что на мою тушку выписано кредитов больше чем я и мои родственники стоим вместе на рынке органов.
А по поводу злых дядь, которые могут захапать себе выпуск этих сертификатов и никого туда не пускать и цену заломить, так они могут захапать его и сейчас, это вопрос правовых норм и регламентов, управляющих деятельностью. Та же УЦ-шка ФНС может выдавать сертификаты бесплатной, а может и за мзду малую в качестве кормления недоросли из новой аристократии. И у недоросли будет всё в полном ажуре. Нужно не механизмы уродовать, а дядь сажать и в запущенных случаях расстреливать…
1. Есть паспорт
2. Есть бумажка, на которой написано «Иван Иванович» и снизу подпись «нотариус Петров»
3. Есть бумажка, на которой написано «Иван Иванович» и стоит печать конторы «Рога и копыта»
4. Есть бумажка на которой написано «Вася»
Это 4 разных бумажки с 4-я разными уровнями доверия. 1-я самая доверенная. Если я заявлюс с паспортом, народу придётся поднапрячься, чтобы доказать, что я-не-я, если рожа с паспорта сойдётся с рожей обращающегося. Вот и все уровни доверия.
1. Нет, это порядок существования системы идентификации субъектов государственных отношений. Оно должно было существовать, или прорабатываться до выдачи первого сертификата. А сейчас нужно всё бросить, и создавать такую систему, поскольку в противном случае мы получаем огромное пространство слабоуправляемых процессов, которые могут привести к плачевным результатам для госвласти. Если госсистемам идентификации не доверяют, то вскоре не будут доверять и государству, что черевато.
2. Большая часть людей, работающих с сертифкатами — люди, их подготовка по работе с этими сертифкатами в лучшем случае — листовка-памятка. Людей нужно готовить к работе с инструментом и инструмент должен быть подготовлен к работе с людьми. На данный момент можно нарваться на ЦС, который без токена ключа не выдаст. Кроме того во многих случаях полезно иметь несколько токенов, для работы нескольких специалистов. В любом случае, по сертификату на площадку — это проблема.
За что люблю российскую систему государственный сервисов, так за то, что при наличии паспортной службы при МВД, Госуслуг (уже претендующих на идентификацию народа), МинЦифры и всяких ГУЦ, сертификаты гражданам будут выдавать налоговики. Вот не получается у нас нормальная иерархия служб, всякий раз «кто может, тот и тянет»…
Но ведь действительно не все УЦ одинаково полезны. Что вы с этим предлагаете делать?
Подписывать их другим сертификатом ГУЦ. То есть разные цепочки доверия для разного класса проверок. Если для совершения каких-то действий нужно быть уверенным, что человек точно реальность — подписываем сертификат ЦС сертификатом ГУЦ соответствующего класса, а сам ЦС при этом попадает на адовую систему проверок и параллельной верификации выданных сертификатов постфактум (выдали сертификаты, а службы аудита от ГУЦ проверила более 50%, что они относятся к реальным людям и эти люди вообще в курсе, полученных на их имя сертификатов). Ну и ещё плотная работа ФСБ-шного противошпионского главка по сотрудникам центра. И если что, тот же главк тянет человека по соответствующим статьям об измене Родине и диверсиях… Не хочешь такого ужаса — подписывайся сертификатом классом пониже… В результате, если сертификат пользователя по цепочке доверия доходит до сертификата ГУЦ соответствующего класса доверия, мы ему доверяем, если нет, то не доверяем. А положение с 100500 ЦС, какие-то из которых хорошие, какие-то плохие, а понять это можно только по статьям на хабре — это не PKI, а детский сад — штаны на лямках…
Про USB-hub извините, не понял, что вы хотели этим сказать.
Не знаю как Вы, я я наблюдал у народа, плотно работающего с различными площадками тендеров и торговли, целые горы токенов, которые иногда нужны прям почти все сразу, поэтому выделенную машину под работу с площадками (либо машину сотрудника, что с ними работает) нужно было дополнительно комплектовать USB-hub-ом, так как портов под все токены не хватало. Нет, если сертификаты выписывались нашеми спецами, мы обычно пытались создавать контейнеры на уже имеющихся токенах, но это не всегда возможно, и почти всегда бухгалтерия с новой площадкой получала ещё один токен.
Одно неприятно, из-за бардака и безответственности в вопросах идентификации и аутентификации граждан с использованием ЭЦП, уже выделяются хорошие УЦ и все остальные. Занимательная картина средней организации, работающей с различными площадками и USB-hub-ом для всех овердофига токенов, скоро начнёт просачиваться в жизнь обычных людей… Это дорога в ад товарищи, с чем всех и поздравляю…
Ну вообще, проблему качественно разработали и досталось всем. AMD не исключение. Intel просто перегнул палку с оптимизациями. Другое дело, что с OoO сложно что-то сделать в подобных сценариях атак, поскольку есть общий кеш и исполнение кода, из будущего уже в настоящем. Чтобы качественно закрыть все возможности атак, нужно либо предисполнение делать на другом наборе кешей, либо эти кеши как-то особо закрывать, что явно угробит весь профит от данного предисполнения...
В статье поются дифирамбы Out of Order, который стал источником уязвимостей, с которыми крайне сложно бороться, а выключение его на превращало камень в тыкву. Причём проблемными оказывались и ARM и x86. Нужно ли нам в это болото?
Никто не знает как правильно, поэтому слабые духом делают так же. Процессоры, которые пошли этим же путём, мы знаем, это и Байкалы. Мне кажется второй Байкал от МЦСТ будет лишним для рынка России, не отличающегося масштабами. А SPARC и собственный VLIW вполне хорошие запасные варианты.
И ещё раз. Да, я согласен, что Эльбрус для задач общего назначения странен. И не за счёт VLIW, а за счёт того, что там всё плохо с переключением задач. Как говорилось на какой-то конференции, она там крайне дорога. Я не думаю, что он пойдёт в массы. Скорее в массы пойдёт вполне предсказуемый Байкал, поскольку АРМ-ом и MIPS сейчас никого не удивишь. Эльбрус - это специальные и большие супер машины и числодробительные ускорители, там как кажется его удастся раскрыть. Но нет у нас сейчас даже намёков на интерес к таким машинам. А когда появится МЦСТ уже сдохнет и разложится. Поэтому пытаются найти нишу для архитектуры, с надеждой на светлое будущее.
Китайцы в 90 делали дрянь, сейчас они делают нам почти всё чем мы пользуемся. Чтобы делать хорошо, нужно учиться. А учиться без проб и ошибок не выйдет. Чтобы оригинальная архитектура давала производительность на уровне мировых аналогов, нужно производство и разработку на уровне мировых аналогов. Где это взять, если не развивать самим? Кто даст технологии мирового уровня, какой дебил добровольно отдаст своё конкурентное преимущество в капиталистическом мире. Долго учится, подглядывая у лучших, а потом сразу сделать шедевр, который их всех затмит - такое бывает только в сказках. Совершенство - тяжёлый труд нескольких поколений, когда на старте имеем дрянь, которая со временем становится совершенней. Эльбрус стартовал с высокой базы, и сразу стал не полным дерьмом, а вполне рабочей вещью. Дальше совершенствование, ввод дополнительных блоков, улучшающих подклассы задач, сопроцессоров, и возможно вынос транслятора x86 в отдельный чип, а лучше постепенно от него отказываться в подлинейке моделей. Но это работа на будущее, а пока пользуемся тем, что имеем, и судорожно придумываем, что нам нужно в будущем, чтобы определить приоритеты развития платформы. Просто "сделайте нам как у них, только у вас, и также быстро" это не вектор развития, это констатация его отсутствия.
Повеселило. В нынешних условиях это как? Существенная часть продуктов работается по схеме тяп-ляп и в продуктив, и побольше хайпа. Откуда столько негатива к планомерной рутинной работе. Продвигать продукт возможно они и хотят (и нет такого разработчика, который не хотел бы широкого распространения своего детища), но есть объективные проблемы:
Начиная с первого появления живых образцов, вокруг архитектуры клубится негатив со стороны "разбирающейся в теме общественности". Сражаться с ветряными мельницами в виде людей, которым и интелов с армами вполне достаточно - глупо. В МЦСТ явно есть на что потратить деньги без попыток снизить кислотность общественной среды.
Отсутствует образ будущего со стороны государства и "общественности". Что нужно от машины на горизонте 10-15 лет, куда стремиться. На рынке, где архитектура Эльбруса всюду инородна нет смысла заниматься активным продвижением, поскольку на данный момент сам процессор страдает от бича российской действительности, когда нужно уметь и нашим и вашим, и Intel-ом прикинутся и быть не интелом, для всяких спец-контор.
Существует заказчик (как говорят), которого процессор устраивает, так зачем распылять силы на продвижение, если можно их сосредоточить на продукте. Динамика прироста возможностей, у процессора вполне нормальная.
ИМХО, Эльбрус адекватный процессор, с вполне хорошей производительностью. Для разработки топовых процессоров способных тягаться с гигантами нужно ни одно уцелевшее неведомо как советское НИИ, хоть как-то причастное к изготовлению СБИС, а комплекс этих самых НИИ и опытно-производственная база, чтобы не нужно было на Тайване за 100500 регулярно дорожающих денег заказывать опытные образцы для натурных испытаний. Нужна политика партии на развитие своего, а не нынешнее "импортозамещение", где большая часть всего для галочки. Ну и образ будущего, когда все понимают, что мы строим и спланировано движутся к поставленной цели. Необходимость тратить транзисторы на транслятор в процессоре идёт из принятого ещё в 70-тые курса на облегчение цельнодратия с прогрессивных и умных американцев их прогрессивного и умного софта. Мы ж не можем у нас совок и лапки... Ну и для того, чтобы продукт вывести не через 30 лет, а сильно раньше. Когда у нас будет гордость и желание обеспечивать себя ПО, а не тырить или закупать заморское чудо чудесное, в товарных объёмах, тогда и достоинства Эльбруса раскроются, а влияние недостатков будет уменьшено. Хороший пример - Японцы, у которых две тяжёлые машины от фуджика собраны на своём, не так чтобы хайповом, процессоре. На АРМ-е, когда это не было ещё так модно и Спарке, который не особо признан в HPC.
Сколько недостатков у Эльбруса нет, но это последний оригинальный Российский процессор. Только поэтому его стоит тянуть и активно использовать во всяких специальных и закрытых системах. Разучимся делать оригинальные вещи, можно закутываться в простыню и тащится на кладбище, ничего путного в будущем уже сделать не сможем.
ORM сокращает время разработки и делает код понятным не знакомым с SQL людям. Однако, на всех конференциях и во всех видео, базёры, при упоминании ORM-а, начинают страшно меняться в лице и изображать лютую душевную боль. Я сам смотрел на поведение PostgreSQL с человеческими и с ORM запросами. У меня волосы шевелились на всех местах, ибо где было достаточно 1-го запроса, эта гадина пускала в базу 10. Возможно я не умею готовить Алхимию, но что-то мне подсказывает что проблема глубже. ORM вполне может стать проблемой при росте, но это моё субъективное ИМХО ORM-о ненавистника.
При построении аналитики Вам придётся обратно номализовывать эту структуру, разбирать её по сущностям и раскладывать по отношениям у РСУБД, в противном случаем придётся руками писать всё то, что SQL умеет уже десятилетия. Вся мощь SQL-я строилась для аналитики и раскрывается на базах нормализованных хотя бы до 3-ё нормальной формы. Тогда с данными работать приятно и интересно.
2. Кто в здравом уме развесистую схему данных под ORM выставляет под нагрузку, ну кроме хипстеров с их стремлением к чистому коду. Частый код он в приложении хипстеров, а если его суммировать с АДОМ ОРМ-а результирующая будет грязнее сточной канавы.
<Сарказм>А вообще, стоит позавидовать парням, что их сценарий улёгся в данный профиль хранения. Я б наверно пошёл дальше и хранил вообще сущности в файлах, а индексы в memcashd, и вообще вышвырнул этот сторедж. Кому он нужен такой тормозной</Сарказм>. И да, в шутке про файлы только доля шутки. Принять имя файла за ключ, а содержимое за значение, подобрать вменяемую ФС и вложенность директорий, и может неплохо получится. А главное этот стор можно разместить много где и жрёт он не так существенно. Есть много проблем, но всё-таки… Ну это так, мысли вслух.
А почему не завести NAS с множеством zfs пулов и не делать zfs send | ssh backup@nas zfs recv, выбирая пул на NAS по каким-то признакам, например по группе серверов или имени кластера, если их несколько. И потом слать инкрементальные копии между 2-я snapshot-ами: старым (который уже отправлен) и новым (выполненным сейчас) через тот же send/recv. Для целей автоматизации старый, после передачи, можно грохнуть а новый переименовать в старый…
И ZFS у вас на Linux?
В FreeBSD и OpenBSD есть специальный функционал, для синхронизации состояний соединений, чтобы при передаче трафика между нодами statefull firewall оставался работоспособным. ОЧЕНЬ хочется верить, что здесь подобный механизм, поскольку просто перекачивать кучи говнища из кучи и стеков из экземпляра в экземпляр — верный путь вырастить какое нибудь чудовище в этой чаше Петри…
Суррогат вроде Google Auth, Microsoft Auth, Yandex Key — это всего лишь суррогат. На каких то моделях устройств это всё завязывается на биометрию, где-то закрывается пином, что не так чтоб сильно улучшает ситуацию. Плюс, это хоть и хитро сгенерированный, но тоже пароль и передаётся тот пароль в том же канале связи, и может программа от того пароля попасть неведомо куда. В общем по своей сути, это тот же пароль с теми же недостатками, хотя в немного подправленном виде.
А вообще, в идеале аутентификация с применением нескольких биометрических данных (в зависимости от серьёзности системы или операции до нескольких одновременно), должна проходить вне основного канала передачи данных через систему посредник. Но опять таки, сдесь нужно думать о схеме работы такой системы, защиты её от предприимчивых людей во власти и за её пределами и обеспечивать массовость и вездесущесть терминалов этой системы, что явно не входит в какие-либо планы.
Это мысль в правильном направлении, но с малым горизонтом. На самом деле имеется пара огромных проблем:
Из этих бед, а точнее из попыток решения их по-быстрому, путём наименьшего сопротивления, и рождается использование почты пользователя, поскольку это самый простой способ его идентификации (попробуйте придумать всем уникальные логины, которые можно запомнить, а почта это сама как-то решает) и связи с ним, и СМС как второй фактор аутентификации и канал оперативного оповещения. Я не думаю что нам нужна гос. почта (ну иная чем она есть на гос. услугах, когда всякие ФНС-ы шлют тебе всякие письма счастья) и гос. СМС-ки. Нам нужна стройная система решающая вышеперечисленные задачи. А пока эти задачи (а они вообще стоят перед всеми этими комитетами цифровизации и иными электронными государствами??!...) не будут решены, к сожалению СМС-ки и почта самое малое из зол. В конце концов, от спец. почты придётся хранить спец пароль… а с хранением паролей у народа ситуация сильно хуже чем с вдумчивым чтением СМС-ок…
И да, для параноиков есть ЭЦП, которая даёт чуть большую защиту, чем просто авторизация по СМС-кам, по крайней мере теоретически.
А по поводу злых дядь, которые могут захапать себе выпуск этих сертификатов и никого туда не пускать и цену заломить, так они могут захапать его и сейчас, это вопрос правовых норм и регламентов, управляющих деятельностью. Та же УЦ-шка ФНС может выдавать сертификаты бесплатной, а может и за мзду малую в качестве кормления недоросли из новой аристократии. И у недоросли будет всё в полном ажуре. Нужно не механизмы уродовать, а дядь сажать и в запущенных случаях расстреливать…
2. Есть бумажка, на которой написано «Иван Иванович» и снизу подпись «нотариус Петров»
3. Есть бумажка, на которой написано «Иван Иванович» и стоит печать конторы «Рога и копыта»
4. Есть бумажка на которой написано «Вася»
Это 4 разных бумажки с 4-я разными уровнями доверия. 1-я самая доверенная. Если я заявлюс с паспортом, народу придётся поднапрячься, чтобы доказать, что я-не-я, если рожа с паспорта сойдётся с рожей обращающегося. Вот и все уровни доверия.
2. Большая часть людей, работающих с сертифкатами — люди, их подготовка по работе с этими сертифкатами в лучшем случае — листовка-памятка. Людей нужно готовить к работе с инструментом и инструмент должен быть подготовлен к работе с людьми. На данный момент можно нарваться на ЦС, который без токена ключа не выдаст. Кроме того во многих случаях полезно иметь несколько токенов, для работы нескольких специалистов. В любом случае, по сертификату на площадку — это проблема.
Подписывать их другим сертификатом ГУЦ. То есть разные цепочки доверия для разного класса проверок. Если для совершения каких-то действий нужно быть уверенным, что человек точно реальность — подписываем сертификат ЦС сертификатом ГУЦ соответствующего класса, а сам ЦС при этом попадает на адовую систему проверок и параллельной верификации выданных сертификатов постфактум (выдали сертификаты, а службы аудита от ГУЦ проверила более 50%, что они относятся к реальным людям и эти люди вообще в курсе, полученных на их имя сертификатов). Ну и ещё плотная работа ФСБ-шного противошпионского главка по сотрудникам центра. И если что, тот же главк тянет человека по соответствующим статьям об измене Родине и диверсиях… Не хочешь такого ужаса — подписывайся сертификатом классом пониже… В результате, если сертификат пользователя по цепочке доверия доходит до сертификата ГУЦ соответствующего класса доверия, мы ему доверяем, если нет, то не доверяем. А положение с 100500 ЦС, какие-то из которых хорошие, какие-то плохие, а понять это можно только по статьям на хабре — это не PKI, а детский сад — штаны на лямках…
Не знаю как Вы, я я наблюдал у народа, плотно работающего с различными площадками тендеров и торговли, целые горы токенов, которые иногда нужны прям почти все сразу, поэтому выделенную машину под работу с площадками (либо машину сотрудника, что с ними работает) нужно было дополнительно комплектовать USB-hub-ом, так как портов под все токены не хватало. Нет, если сертификаты выписывались нашеми спецами, мы обычно пытались создавать контейнеры на уже имеющихся токенах, но это не всегда возможно, и почти всегда бухгалтерия с новой площадкой получала ещё один токен.