Валентин, поэтому проблему решают на этапе проектирования архитектуры ИС. Тогда возможно решить задачу элегантно и относительно бюджетно. Все крупные проекты в Интернет идут по такому пути. Можно почитать блог Ивана Блинкова об архитектуре крупных проектов.
Для гигантов индустрии характерен переход к использованию географически распределенных файловых систем для хранения файлов, где задача отказоустойчивости решена уже. Применению реплицируемых сервисов баз даных и nosql хранилищ. И балансировка трафика между экземплярами сервиса. т.е. роль экземпляра сервиса сведена лишь к исполнению кода и без локального хранения чего-либо существенного.
В одном ДЦ - можно heartbeat или pacemaker https://habr.com/post/107837/
Для горячей копии данных удобно использовать DRBD или распределеннные ФС.
Для географически распределенной системы решается только с помощью архитектуры.
В простых случаях, когда нужно только раздавать контент, то можно обойтись балансировкой. Например, с помощью round robin DNS и нескольких балансеров на haproxy перед серверами с контентом. Но это тоже не панацея, если ляжет вся DNS зона. В некоторых случаях полезно завести несколько доменов в разных зонах.
Евгений, попробуй без order by выполнить, копирование во временную таблицу дает основной вклад. если проблема здесь, то есть смысл order by разгрузить, чтобы он стал эффективным.
Валентин, vmoton не обеспечивает отказоустойчивость https://www.vmware.com/ru/products/vsphere/vmotion.html - тут ни слова об этом , оно и понятно, если хост или сторадж ляжет - живую миграцию сделать будет невозможно.
для решения этой проблемы есть отдельная технология- VMware Fault Tolerance
здесь по делу описана суть и особенности этой технологии: https://www.vmgu.ru/news/vmware-fault-tolerance-in...
Законы физики здесь тоже обойти не удалось - внизу статьи перечислены все существенные ограничения для этой технологии. Чуда не случилось.
Контейнер в облаке - физически контейнер на физической машине облачного провайдера - это значит, что в случае отказа - контейнер и его данные будут недоступны. можно ли будет достать когда-либо актуальные данные - неизвестно.
Облако - это маркетинговое понятие, которое натянуто на вполне обычные технологии виртуализации, которые сами по себе никаких чудес сделать не могут.
Конкретно с Амазон были аварии, когда лёг весь регион и много клиентов пострадало.
и не все данные были восстановлены. У rackspace несколько дней лежал DNS, положив всё у клиентов. Облако - это иллюзия с точки зрения отказоустойчивости.
Облако хорошо для динамического получения и распределения вычислительных ресурсов. Для экономии затрат на железо за счет высокой плотности приложений.
Можно еще напомнить про пожар hosting.ua, где сгорело все здание датацентра.
Поэтому если хочется получить действительно отказоустойчивый сервис - нужно это закладывать в архитектуру. И в этой архитектуре должен быть решен вопрос репликацией данных "на живую".
Павел Романов, смотри в сторону framework на python - пусть это будет django или любой другой каркас, на который вешать свой функционал. Можно конечно PHP joomla, drupal, но на PHP кодеров много, а грамотных мало.
В общем виде стек называется LAMP - Linux, Apache, MySQL, PHP/Python/Perl
По MS Access ничего путного сделать нельзя. Только прототип для себя на коленках. Там много проблем.
не надо .Net , не надо привязываться к винде, не надо пилить толстого клиента - это все дорогие и бесперспективные занятия.
.Net уже не является актуальной технологией как и Wnidows. Есть смысл вкладываться в только кроссплатформенные решения - а это WWW стек.
Microsoft как кидал и так и кидает своих клиентов. Нет смысла туда платить деньги.
К тому же на рынке труда .Net - тоже узкая ниша - мало вакансий мало специалистов. Скоро совсем будет экзотика.
alex-1917, еще надо резерв на полку положить.
обычно, потребности растут , поэтому кроить несколько тысяч рублей и щедро тратить слоты - потом приведет к большим затратам. + питание и тепло отведение, так что в конторе прямая экономия стоимости за ТБ не факт что экономия даже сразу.
только не "в ту же таблицу", а "из той же таблицы"
допускаю, что часть запроса опущена, в полном виде такая конструкция может потребоваться для дополнительных манипуляций с данными при выборке, которые в вопросе не показаны.
lega Не совсем так, во-первых, есть целая статья на эту тему: https://habr.com/company/mailru/blog/335326/ :-)
во-вторых, LA связан не только с нагрузкой на вычисления CPU, но зависит и от ввода вывода.
При определенных обстоятельствах вполне можно наблюдать LA в несколько тысяч, при фактически не загруженных процессорах.
Pavel Tananykhin, можно перевесить ssh порт на нестандартный, чтобы не мучать атакующих и меньше этим заниматься. Но могут быть неудобства при активной работе с ssh, например с rsync.
kalapanga, согласен, если повезет с выбором - то будет успех, если не повезет - то будут проблемы. Я сам занимался наймом людей - работа с исполнителями - это тоже работа и без погружения в детали проекта праздника точно не будет. Насчет "с умом" - можно привести много примеров высоко бюджетных проектов, делавшихся в интересах серьезных и именитых компаний, которые все равно заканчивались фиаско. Поэтому, если даже в крупных известных компаниях не всегда знают как достичь гарантированного успеха, при этом имея хорошие бюджеты и опытных сотрудников. То что говорить о тех, кто этим занимается случайно? Это однозначно риск.
Риск можно снизить - условиями договора, чтобы исполнитель был заинтересован в успехе проекта - впереди должен быть не только плата за работу, но и хороший приз. Т.е. нужно мотивировать исполнителя успеть, и сделать это хорошо. Второй аспект - отбор исполнителя - здесь мне кажется важными - взаимное понимание обсуждаемых проблем. хороше портфолио успешных проектов - чем больше проектов исполнитель сделал - тем очевиднее вероятность его успеха в следующем проекте.
Melkij, только не надо так делать - сейчас собирать рейд из 11 дисков очень дорогое удовольствие - слишком много нужно слотов. гораздо выгоднее собирать массив из дисков крупного объема.
Для гигантов индустрии характерен переход к использованию географически распределенных файловых систем для хранения файлов, где задача отказоустойчивости решена уже. Применению реплицируемых сервисов баз даных и nosql хранилищ. И балансировка трафика между экземплярами сервиса. т.е. роль экземпляра сервиса сведена лишь к исполнению кода и без локального хранения чего-либо существенного.