> Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.
Получил такую каку буквально пару дней назад. До этого 2 года сервер работал стабильно и каждый день делал резервную копию из LVM снапшета. Система Debian 6.
> К сожалению, в больших проектах не обходится без частных случаев и программисты при сложных запросах пишут либо raw sql, либо полагаются на то, что им предлагает базовый функционал ORM. Это выглядит не совсем красиво или создает достаточно большую нагрузку на базу данных.
Есть еще один вариант. Делают денормализации, вешают обработчики событий на CRUD операции, превращают SQL в NoSQL и на выходе получают не проект, а какашку.
Возможно вопрос не совсем по теме, но очень хотелось бы получить ответ. На сколько хорошо совместимы между собой SFP+ порты на коммутаторах и сетевых картах при подключении через твин аксиальный кабель? Будут ли работать конфигурации: сетевая картасетевая карта, сетевая картакоммутатор, коммутаторкоммутатор? Конкретнее по моделям intel X520-DA2 и dlink DGS-3420-28TC.
Добавлю пару замечаний:
— Приложения достаточно удобно хранить в отдельной директории, например, apps.
— Шаблоны имеет смысл хранить все вместе, но отдельно от приложений (т.е. выделить под все шаблоны отдельную директорию). Такая структура подталкивает хранить шаблоны в структуре app_name/tmpl_name и коллизии сразу видны на глаз. Кроме того шаблоны обычно уникальны для каждого проекта (в отличие от приложений, которые полностью или частично реюзабельны), а если шаблон универсальный то вообще имеет смысл задуматься о создании пакета.
Что по факту означает HBA? Что SAS контроллер способен работать в такой сетевой среде с полками и SAS коммутаторами? Чем отличается от обычного SAS контроллера? SAS HBA контроллер является только клиентом? Или же сервер с SAS HBA адаптером может сам выступать в роли дисковой полки?
Люди добрые, а можете просветить что такое SAS HBA, SAS коммутатор? Как можно построить сеть хранения данных на SAS? Какое еще нужно оборудование? По данным вопросам гуглил, но не нашел исчерпывающей инфы — видимо плохо гуглил.
Все бы хорошо, но мне кажется что samba4 в роли контроллера домена AD еще для продакшена еще не готова. Для сети 50 и более лучше купить лицензию на мастдая. Слишком сложна инфраструктура AD. Потерять домен из-за какого нибудь бага в Samba4 будет обидно. Кроме того samba на данный момент не полноценная замена мастдаю, например нет поддержки сайтов (если я не ошибаюсь). Пожалуй AD одна из немногих служб которую пока что (полноценно) не поднять на *nix системах.
Соглашусь с автором. Хранимые процедуры вещь мощная их использовать надо осторожно. В одном из проектов я превратил postgresql в RPC сервер, ради эксперимента. Работало бысто, но логика размазалась, были проблемы с дублированием. Еще приходилось администрировать один проект с большим количеством хф. Было очень неприятно что он оказался привязанным к одной конкретной БД.
Поэтому пришел к мнению что одно из лучших решений для малых и средних проектов использовать ORM или прописать слой абстракции от данных самому.
К стати ORM в малых и средних проектах справляется с задачей на 80%-90% и экономит время разработки. Другое дело что остаются 20%-10% с которыми ORM' трудно справиться. Обычно это какая-то аналитика с агрегациями. И тут заранее нужно подумать перед выбором ORM как это будет решаться. Я работал над средним проектом в котором ORM был выбран не верно. Из-за аналитики БД погрязла в денормализациях.
Относительно node.js уже думал, можно повторно использовать код на сервере и клиенте. Но под него нужно уметь писать, framework'ов пока не шишь для него. Да и «в нем все работает быстро за исключением твоего кода» или как там оно звучало. Ну и ограничен ты JS и его производными.
По второму пункту. Например для уменьшения дублирования кода создал API для валидации данных, на JS это было бы громоздко. Но вот под концепцию REST оно не сильно подходит. Это скорее RPC.
Меня уже долгое время интересует вопрос: когда нужно разделять сервер и клиент, когда действительно нужно делать клиента толстым и писать все эти REST API, RPC. Понятно что если помимо веб интерфейса планируется мобильное приложение, десктопное приложение или еще какая нибудь экзотика, то нужно API. Но если планируется только веб морда, действительное ли нужно все это воротить?
Что бы не быть голословным: работал над крупным проектом. Был сервер с REST API и толстый веб клиент. Проблем было море, вот те которые относятся к теме:
— бизнес логика дублировалась и на клиенте и на сервере. Это к стати общая проблема толстых клинтов.
— некоторые вещи не подходили под REST API, а скорее тяготели к RPC. Смотрелись они чужеродно.
Что бы добавить справочник нужно было сделать кучу рутины — к концу уже начинал во всю зевать. И самое обидное что не было особых причин делать обе стороны толстыми. Релтаймность можно было достигнуть и без этого. Тем более нужно она была всего в паре мест.
Получил такую каку буквально пару дней назад. До этого 2 года сервер работал стабильно и каждый день делал резервную копию из LVM снапшета. Система Debian 6.
Есть еще один вариант. Делают денормализации, вешают обработчики событий на CRUD операции, превращают SQL в NoSQL и на выходе получают не проект, а какашку.
P.S. Сам однажды вляпался в такое г.
— Приложения достаточно удобно хранить в отдельной директории, например, apps.
— Шаблоны имеет смысл хранить все вместе, но отдельно от приложений (т.е. выделить под все шаблоны отдельную директорию). Такая структура подталкивает хранить шаблоны в структуре app_name/tmpl_name и коллизии сразу видны на глаз. Кроме того шаблоны обычно уникальны для каждого проекта (в отличие от приложений, которые полностью или частично реюзабельны), а если шаблон универсальный то вообще имеет смысл задуматься о создании пакета.
Поэтому пришел к мнению что одно из лучших решений для малых и средних проектов использовать ORM или прописать слой абстракции от данных самому.
К стати ORM в малых и средних проектах справляется с задачей на 80%-90% и экономит время разработки. Другое дело что остаются 20%-10% с которыми ORM' трудно справиться. Обычно это какая-то аналитика с агрегациями. И тут заранее нужно подумать перед выбором ORM как это будет решаться. Я работал над средним проектом в котором ORM был выбран не верно. Из-за аналитики БД погрязла в денормализациях.
По второму пункту. Например для уменьшения дублирования кода создал API для валидации данных, на JS это было бы громоздко. Но вот под концепцию REST оно не сильно подходит. Это скорее RPC.
Что бы не быть голословным: работал над крупным проектом. Был сервер с REST API и толстый веб клиент. Проблем было море, вот те которые относятся к теме:
— бизнес логика дублировалась и на клиенте и на сервере. Это к стати общая проблема толстых клинтов.
— некоторые вещи не подходили под REST API, а скорее тяготели к RPC. Смотрелись они чужеродно.
Что бы добавить справочник нужно было сделать кучу рутины — к концу уже начинал во всю зевать. И самое обидное что не было особых причин делать обе стороны толстыми. Релтаймность можно было достигнуть и без этого. Тем более нужно она была всего в паре мест.