postgree

Добрый день. В этом году забили последний гвоздь в крышку гроба UCM и выгородили огород из самописных костылей. SAP XI вроде как тоже хоронить собираются. Вопрос новой шины вроде как остро стоит в текущие не самые денежные времена. Конфигурирование готовых продуктов от именитых вендоров под наши требования выливалось в сумасшедшие деньги, поэтому решили костылять. Неплохой геморрой поимели c управлением доступом. Если у вас куча систем от разных вендоров, костыли вбивать все равно придется. + у нас загрузка каналов именно на хранилище достигает пары гигабит/сек. Прирост в месяц около терабайта. Коэффициент оптимизации ~ 2.8 Поднимается вопрос о модификации почтового сервера, чтобы вложения сразу заменять на ссылки в хранилище.
Посмотрите коробки: Топ 20 по хз какой версии.
Выбор на самом деле будет зависеть не от базовых требований, т.к. базовые требования покрывает куча продуктов. В нюансах все зло xD.
Извиняюсь, за сумбурный поток мыслей, поэтому лучше списаться в скайпе. А вообще напишите статью по результатам исследования.

Теоретически на той же нагрузке + 25-30% i7-4770 вытянет, если смотреть на тесты в попугаях.

Аналогичные конфигурации с такой же памятью, дисковой подсистемой, но с одним процессором, скажем, Intel® Core™ i7-4770 (наиболее распространенный процессор у хостеров на данный момент) стоят на порядок дешевле.

Разница в платформе. Двухсокетные конфигурации хоть мало мальски серверные. Односокетные - иногда это реально самое дешевое железо, засунутое в тонкий корпус. Что в принципе не является серьезным минусом. Вот только на таком железе однозначно softraid. Соответсвенно - как вы будете реализовывать минимальную отказоустойчивость, если будете ставить esxi?
При таком количестве пользователей, будь я руководителем, я бы однозначно требовал отказоустойчивость или восстановление системы с даунтаймом не больше 15 минут. Если вы будете брать сервер с небольшими SSD они могут быть уже хорошо поюзанными.
При себестоимости сотрудника в 1000$ месяц стоимость часа простоя будет (60*1000)/160 = 375$ не считая упущенной прибыли. Т.е. месячная экономия перекрывается одним инцидентом.

Что вы хотите получить? строку с датами для каждой задачи? тогда:

DELIMITER $$
--
-- Создать функцию "calc_date_range"
--
CREATE FUNCTION calc_date_range(date_start DATE, date_end DATE)
RETURNS text CHARSET latin1
SQL SECURITY INVOKER
BEGIN
DECLARE res_text text;
DECLARE tmp_date date;
IF(date_end < date_start) THEN
RETURN '';
END IF;
SET tmp_date := date_start;
SET res_text :='';
WHILE(tmp_date<=date_end) DO
SET res_text := CONCAT(res_text,',',DATE_FORMAT(tmp_date, '%m-%d-%Y'));
SET tmp_date := DATE_ADD(tmp_date, INTERVAL 1 DAY);
END WHILE;
RETURN SUBSTRING(res_text,2);
END

Либо вы хотите получить список дней для всех задач под условие. Для этого придется заполнить табличку "календарь" (например с полями (`cdate`,`weekend`,`lolshta`))
И получить запросом вида:

SELECT c.cdate FROM tasks t
INNER JOIN calendar c ON c.cdate >= DATE(t.date_from) AND c.cdate<=DATE(t.date_to)
WHERE
t.USER_ID = 17
AND t.status = 4
AND NOT c.weekend = 1
GROUP BY c.cdate;

Могу предположить, что идет фулскан индекса, т.к. сфинкс при фильтрации по атрибутам, без поиска просмотрит весь индекс, рассчитает все значения, попадающие под условие, отсортирует, наложит лимиты и вернет результат. Т.к. после каждого запроса можно получить мета информацию. Благодаря такому механизму можно выводить пагинацию без дополнительного запроса count(*). И да, мне кажется вы не для того кейса используете инструмент. Если все же очень надо, придется с этим смириться.

1) Какие марки/модели сейчас наиболее надежные (WD/Toshiba/Seagate)?

Тошиба подешевле и хитачи (ультрастар) подороже.
2) С точки зрения экономии финансов какой объем на сегодняшний день оптимально брать?
Если просто самые эффективные по соотношению объем/цена то 4Tb
3) Есть ли особенности хранения большого количества мелких файлов (хтмл-файлы, имейджи к ним)?
Насколько мелкие? Как вы будете объединять дисковое пространство? Фактически тут играет размер получаемого после объединения блока. Чем больше блок, тем больше производительность на больших файлах, и тем больше оверхед по дисковому пространству на мелких файлах.
Я у себя считал оверхед на тестовой выборке файлов из таблички метаданных:

SELECT (sum(ceil(f.size_/:block_size))*:block_size)/ sum(f.size_) AS koef FROM files f

и на моих данных уменьшать размер блока меньше 16384 не имело смысла, т.к. разница в пару процентов не принципиальна.

и не следует класть миллионы файлов в одну директорию....

Вы будете держать файлы в фс, бд или свои велосипеды?
Файлы раскладывал по директориям по алгоритму /file_dir/{md5h::substr(0,2)}/{md5h::substr(2,2)}/sha256h
Хеши нужно было просчитывать по задаче, так что не особо напрягался за экологию.

PhantomJS - использую для парсинга сайтов одностраничек и пр. Можно не реверсить JS.

Тогда полностью уточните постановку, что есть активность пользователя?

А должность инженера это что? (Вы бы уточнили немного, что вы делаете.)
Путь из разраба был таков:
1. Разраб (Контора №1).
2. Тимлид.
3. Аналитик (человек встал, послал проект глубоко и ушел, пришлось дыры закрывать)
4. Снова разраб в единственном экземпляре над задачей (контора №2).
5. Затычка во все дыры с должностью главный специалист (; (контора №3).
6. Тимлид в пожарной комманде (контора №4).
7. ПМ.
Все случилось в относительно короткий промежуток времени (2 года), можно сказать, самотеком.
Читал про agile, pmbok кусками. Были люди, которые подсказывали, что делать в тех или иных ситуациях. Проекты были уже в работе, когда я на них приходил, и в разной степени тяжести/запущенности.

У себя (дома или где там) используете подсеть отличную от офисной, понимаете соединение на роутере и настраиваете маршрутизацию в офисе на вашу подсеть через впн сервер. Никаких пробросов не нужно.

А что с гипертридингом?