1) удалять сообщения не нужно, их нужно не покпзывать. Делаем отдельное полк deleted
2) select count(tatata) делает это по индексу, где и так он хранится.
3) lastmessage так вообще нужно хранить не в базе, а в памяти
Ну и собственно, когда у нас есть кеширование или ORM, то во многих случаях в базу не нужно будет лазить вообще.
Проблема с разными тригерами одна, они нагружают базу, иногда очень и очень сильно, особенно при операциях удаления, а еще, про них забываешь и они иногда могут творить чудеса... Я не настаиваю, я через хранимки и тригера прошел и если их можно не делать, их делать не нужно. Особенно начинает бесить, когда через два-три года работы базы неработающий до этого тригер вдруг начинает отрабатывать по какому-то условию, при этом и код и данные и условия уже давно не те. Вот тут и начинается зоопарк с откатом стогигабайтных баз, транзакционных логов, перезаливкой архивных данных, поиском проблемы и прочими батхертами и оверхедами с бдениями в праздничные ночи.
С хранимками ситуация ничуть не лучше, особенно, когда у вас распределенная система и некоторые таблицы пошардены на кучу инстансов.
Все относительно, это же почти конечный автомат, а там что последнее, что первое, все едино, но можно и первым пунктом. Да и думал всего минут 10, писал дольше, автору топика и проверять.
386DX: Ну, блин, согласен, всем сразу сэсэде, гигабиты, процессоры квантовыеб фибреканалы на реидах. Вот оно волшебство0то где... Как оные закупят, а производительность на месте останется - так уже и разбираться будут :-)
Лучше пусть collectd запустят и посмотрят что с сервером происходит, тянуть то должен наверное...
Ну и я бы нагрузочное тестирование сделал на предмет сколько же он отдать может - fio рулит.
brammator: Так, у нас ubuntu 14.04, multipath настроен по умолчанию, со стороны DS3400 настороено отдавать два виртуальных диска на один комп, два других на второй. Устройства мапятся в /dev/mapper/mpath1-XXXXX /dev/mapper/mpath2-XXXXX
А некоторые и на демоплатах останавливаются, благо некоторые дешевле грязи и негабаритные и для 3-5 штук свое производство иногда накладно... Как раз по этому пути идут STlabs и NXP... У моторолы обычно дороговато выходит (хотя все относительно)...
Так вроде бы ответил практически на все вопросы, не нравится ардуино (мне тоже), возьмите любой микроконтроллер любого производителя, хоть PIC, хоть STLabs, хоть Motorola (ах, да Freescale), хоть NXP, Intel, Samsung... Берите описание чипа, там есть и схемы подключения, питания и прошивки. Разводите платку, паяете, исправляете ошибки, Покупаете JTAG, подключаете, прошиваете.
ИЛИ, покупаете девелопмент борду с нужным чипом от тех же самых производителей, в комплекте часто и набор софта и JTAG. Разрабатываете софт, а параллельно, по схеме борды, разводите свою фитюльку. Через месяца 3-4 у вас и софт и фитюлька готовы.
Вот по второму пути я и предлагаю пойти - купите себе за ~1500-3000 рублей демо-плату STM32 и разрабатывайте!
Одинаково, по стандарту развитие пар не более 12 сантиметров, как помню, а уж как будут эти сантиметры склеены, связаны или замкнуты - все равно (или почти все равно), все разъемы подпружиненные, а в розетке еще и защелкнуты на ножах, но на характеристики это не влияет.
Тут не только задержки, а еще и накладные расходы.
По накладным расходам, посчитаем. Пакет ethernet по максимуму (не совсем!) равен 1500 байт, из них 18 байт на заголовок ethernet, 22 байта на заголовок TCP, и iSCSI заголовок 48. Итого чистых данных у нас 1412 байт это ~94% от пропускной способности. Но так как по ethernet еще бегает куча всего типа ARP и прочего, то принято говорить о 8-10% накладных расходов. Еще стоит учесть, что не всегда будут гоняться именно большие блоки, отнимите еще 10-20%, получите те самые 20% на круг.
Всё ли так плохо?! Да нет, первое, что нужно учесть - увеличить размер кадра ethernet до например 9000 (так называемые jumbo frames), включаем опцию на коммутаторах и сетевых адаптерах, получаем 8912 байт чистого трафика 99% пропускной способности! :-)
Теперь о задержках (так называемая latency): оно примерно 50-125 us (для 1ge), но может снижаться из-за загрузки коммутаторов/адаптеров/CPU. В принципе нормально. Как повысить отзывчивость? Переходить на 10ge (5-50 us) или infiniband (3-5 us).
Дополнительно, если работаем на 1ge, сделать bonding из двух/четырех портов в один.
Ну и не скупитесь на нормальные коммутаторы (например dlink DGS 3420 замечательно работают и не очень больно, как киски/хуйли-ты-паккард). Где можно ходите оптикой, она нынче как грязь, сразу одномод кладите (с заделом на 10ge).
PS. С другой стороны, если будете полностью переходить на 10ge, то рекомендую посмотреть на infiniband - по стоимости практически тоже самое, а в скорости в 4 раза больше (но есть и нюансы конечно...).
Bulroh: До начала передачи данных происходит так называемый обмен ключами с установкой сессионного (одноразового) ключа шифрования. Обычно обмен начинается таким образом - браузер отсылает серверу список поддерживаемых протоколов шифрования, сервер браузеру - свой список, далее выбирается общий поддерживаемый протокол, опсле этого происходит обмен ключами и генерация сессионного ключа, а уже после этого установка зашифрованного соединения. Вот после установки зашифрованного соединения, если сервер и браузер договорились (а могут и не договориться, в зависимости от настроек любой из сторон), начинается передача самих данных. Т.е. данные в открытом виде не передаются!
Это все определяет например протокол TLS или SSL -https://ru.wikipedia.org/wiki/TLS
Сергей: Ничего плохого нет, если это действительно сайт Васяна, а не его "друга" Гошана. Вот только как узнать, кто из них кто? В сертификате-то оба Васяны.
Сергей: Представьте, что я, будучи провайдером, подменил сайт sbrf.ru с его личным кабинетом, установив прокси на канале, и подписал его самоподписанным сертификатом. Для пользователя это так и будет сайт sbrf.ru, доверяете ли вы этому сайту?
2) select count(tatata) делает это по индексу, где и так он хранится.
3) lastmessage так вообще нужно хранить не в базе, а в памяти
Ну и собственно, когда у нас есть кеширование или ORM, то во многих случаях в базу не нужно будет лазить вообще.
Проблема с разными тригерами одна, они нагружают базу, иногда очень и очень сильно, особенно при операциях удаления, а еще, про них забываешь и они иногда могут творить чудеса... Я не настаиваю, я через хранимки и тригера прошел и если их можно не делать, их делать не нужно. Особенно начинает бесить, когда через два-три года работы базы неработающий до этого тригер вдруг начинает отрабатывать по какому-то условию, при этом и код и данные и условия уже давно не те. Вот тут и начинается зоопарк с откатом стогигабайтных баз, транзакционных логов, перезаливкой архивных данных, поиском проблемы и прочими батхертами и оверхедами с бдениями в праздничные ночи.
С хранимками ситуация ничуть не лучше, особенно, когда у вас распределенная система и некоторые таблицы пошардены на кучу инстансов.