Обсуждение

"взяли, и разогнали! По углам..." ИМХО,всё просто - среди основной темы "системная инженерия", от которой голова пухнет за полчаса, вдруг появились "знакомые массам" слова - база данных, кэш. И набежало любителей поспорить с целью показать свой уровень :-) Жизнь действительно "пошла интересная" - в нашей стране ИНет-каналы стали вполне доступны "за МКАД", и вторая на моей памяти волна неттопов\нетбуков\SaaS имеет щансы на попытки реализации и у нас. А этот процесс связан с развитием серверной части, и тут я вижу не только Насчет одноядерных процессоров - не согласен,дело же не только в распараллеливании ОДНОЙ задачи, а в том, что однозадачных ОС всё меньше. Писать сложные системы - либо использовать метод конечных автоматов, либо разбивать на много "паралельных" задач. Несмотря на большую надежность первого подхода, второй выглядит более понятным. Одно ядро - это затраты на переключение контекста, которые сглаживаются либо большим количеством регистровых групп (помнится, в PDPшных ЦПУ (наш 1801) уже было два "аппаратных контекста" - пользовательский и ОС), либо несколькими ядрами с меньшим количеством регистров. Полагаю, что с т.з. проектирования ЦПУ многоядерность выгоднее многорегистровости. Одноядерный ЦПУ в компьютере "общего назначения" - это типа IBM360. ЦПУ считает, а для других дел есть другие, "умные" подсистемы - ввод\вывод. Попытки ТАК строить ПК почему-то провалились, большинство ПК сейчас "двухпроцессорные" - один для графики, второй для всего остального. А насчет девяти женщин: "одна жена любит, одна жена пищу варит, одна одежду шьет, одна детей кормит - все одна? Тяжелоооо." У идеи с "персистенс в ОЗУ" есть одна засада - при серьёзных проблемах с питанием нужно сбросить данные на носитель. Он либо быстрый и дорогой - что ставит под сомнение целесообразность затеи, либо дешевый и медленный - и нужно успеть сбросить 50Гиг (меньше неинтересно мне), пока ИБП жив. Впрочем, в случае грамотной реализации сериализации (ох..) получится ровный поток, а с ним SATA и сейчас справляется неплохо. Так что осталось дождаться еще одного уполовинивания цен на ОЗУ (или SSD?).

отвлекся... При терминале на столе и хорошем (быстром и надежном) канале пользователю становится неважно, что "там, в серверной". А там, в серверной, вполне может оказаться мейнфрейм (ну да, те самые, которых хоронят уже сколько десятилетий) - с подешевевшей ОЗУ и SSD. Одноядерным ЦПУ тут не место.

Удивительно, но ни разу не было произнесено слово persistence В конце помянул разок http://ailev.livejournal.com/708726.html?thread=6341238#t6341238 :)

У идеи с "персистенс в ОЗУ" есть одна засада - при серьёзных проблемах с питанием нужно сбросить данные на носитель. Он либо быстрый и дорогой - что ставит под сомнение целесообразность затеи, либо дешевый и медленный - и нужно успеть сбросить 50Гиг (меньше неинтересно мне), пока ИБП жив. Ну сбрасывать же инкрементально можно. Вообще достаточно синхронно сбрасывать на диск поток внешних событий и принятых решений. По этим данным, можно восстановить внутреннее состояние. Там где его долго вычислять, то можно асинхронно инкрементально сбрасывать снапшоты состояния. Т.е. восстановление будет с последнего целостного снапшота плюс проигать лог событий. Эта схема хорошо согласуется даже с НЖМД, ибо запись в лог диск быстро пишет, а асинхронный сброс состояния можно группировать, т.е. запись на диск идет не случайная, а пачками. Можно вообще инкременты insert'ами в БД писать (плюс немного апдейтов), потом почистить только мусор нужно. Ну а про SSD я и не говорю.

Мое мнение: жизнь с удешевлением оперативной памяти пошла такая интересная, что persistence неминуемо становится не менее популярными, чем базы данных. Но, как и в случае баз данных, persistence пока предпочитают ваять самостоятельно в каждом конкретном случае, "под себя" (тогда и говорят, что "работают прямо с файлами"). Ничего, и это пройдет. Самое смешное, что реально делают несколько реализаций одного интерфейса, один с файлами работает, другой с БД, третий - еще с чем-то (какой-нить MQ). Т.е. у нас был три интерфейса: файлы, MySQL и MSSQL. Кто-то мне говорил про биллинговую систему, там был файл и БД. У Cameron FIX, основной способ хранения - файл, но по просьбам клиентам они еще несколько интерфейсов сделали (БД, MQ etc).