Насчет загрузки из баз данных — сейчас мы работаем над скриптованием системы (приходиться учитывать разные вкусы потенциальных заказчиков), поэтому загрузка из баз данных в скриптах не составит проблем.
Спасибо!
На самом деле, так как обработка все равно происходит на уровне текста, реализация общения на уровне чата не должна составить особого труда. =)
Извиняюсь, что неясно выразился. Под экспертизой имелось ввиду английское слово expertise и я имел ввиду именно умение. Умение позиционировать продукт на рынке, умение «поднимать волну», понимание проблем высоконагруженных проектов и т.п. Инвестор с такими талантами может сильно помочь проекту на начальной стадии, и большинство «технарей» предпринимателей ими как раз и не обладают. Подросший и оперившийся проект в них видимо уже и не нуждается.
А миллионы есть смысл тратить на масштабирование — тут может и пригодится 30% на маркетинг (примеры типа Zynga). Или там, где взять рыночную долю можно лишь на деньгах, выдавливая конкурентов бесплатным продуктом или демпинговой ценой. Варианты есть, в общем. =)
Смысл имеют только «умные деньги», которые помогут закрыть экспертизы, которых обычно нет (маркетинг, продажи, масштабирование), но которые очень нужны. А так да, не пытайтесь заработать поднимая деньги у инвесторов — зарабатывайте их с клиентов. Деньги нужно поднимать только когда вы четко представляете себе, почему не можете без них обойтись. Porsche Cayenne причиной не считается, а прожить вы можете на гораздо меньшие деньги, чем вам на самом деле кажется.
Если в общих чертах, то это развитие параллельной LRU ветки алгоритмов кеширования под названием CLOCK. Проблема LRU заключается в том, что необходимо постоянно поддерживать актуальный список элементов кеша в тот момент, когда к ним обращаются. Т.е. обратившись к элементу вы переносите его в конец очереди. Это требует локов и плохо масштабируется при большом количестве потоков.
CLOCK решает эту проблему очень элегантно — он просто идет по кругу (как в часах) всех элементов кеша и выгружает те, у которых не установлен флаг 'long'. Если же флаг установлен, то он его просто сбрасывает и оставляет элемент в кеше. При повторном обращении к элементу вам нужно только установить этот флаг. Схема проста и весьма эффективна.
Проблемы начинаются когда сканируется вся база за кешем (тогда даже часто используемые элементы рискуют быть выгруженными из-за множества проходов «по кругу»), и когда к одному элементу обращаются дважды (ему устанавливается флаг и он проживет минимум два прохода по кругу).
CAR решает эту проблему таким же образом, каким это делает схема ARC — он имеет не один, а два круга. И элементы из первого круга попадают во второй только если они действительно очень популярны. Таким образом решается проблема двойного доступа и сканирования базы.
CART отличается от CAR тем, что держит еще и «историю» последних выгруженных элементов, на основании которой он решает в какой из кругов помещать новый элемент.
Ну это не совсем документация — это публикация, связанная с этим алгоритмом. И, конечно, если уже расписывать CART, то нужно описать все доступные схемы кеширования, их достоинства и недостатки. Это уже больше теоретическая задача, на которую хотелось бы выделить время, имплементировать все схемы и сравнить их.
В данном же случае я ставил за цель имплементировать многопоточную схему, а уже получившимся кодом решил поделиться с остальными разработчиками. С этим связан достаточно куцый обзор самой схемы. Хотя стоит отметить, что исходная публикация сама по себе весьма интересна и описывает определенный бекграунд для интересующихся темой кеширования. Возможно стоит сделать ее перевод?
Дайте немного времени, сейчас все починим.
К Мегафону и Кроку отношения не имеем. =)
Их публикации просто вдохновили нас рассказать о нашем подходе.
На самом деле, так как обработка все равно происходит на уровне текста, реализация общения на уровне чата не должна составить особого труда. =)
А миллионы есть смысл тратить на масштабирование — тут может и пригодится 30% на маркетинг (примеры типа Zynga). Или там, где взять рыночную долю можно лишь на деньгах, выдавливая конкурентов бесплатным продуктом или демпинговой ценой. Варианты есть, в общем. =)
CLOCK решает эту проблему очень элегантно — он просто идет по кругу (как в часах) всех элементов кеша и выгружает те, у которых не установлен флаг 'long'. Если же флаг установлен, то он его просто сбрасывает и оставляет элемент в кеше. При повторном обращении к элементу вам нужно только установить этот флаг. Схема проста и весьма эффективна.
Проблемы начинаются когда сканируется вся база за кешем (тогда даже часто используемые элементы рискуют быть выгруженными из-за множества проходов «по кругу»), и когда к одному элементу обращаются дважды (ему устанавливается флаг и он проживет минимум два прохода по кругу).
CAR решает эту проблему таким же образом, каким это делает схема ARC — он имеет не один, а два круга. И элементы из первого круга попадают во второй только если они действительно очень популярны. Таким образом решается проблема двойного доступа и сканирования базы.
CART отличается от CAR тем, что держит еще и «историю» последних выгруженных элементов, на основании которой он решает в какой из кругов помещать новый элемент.
В данном же случае я ставил за цель имплементировать многопоточную схему, а уже получившимся кодом решил поделиться с остальными разработчиками. С этим связан достаточно куцый обзор самой схемы. Хотя стоит отметить, что исходная публикация сама по себе весьма интересна и описывает определенный бекграунд для интересующихся темой кеширования. Возможно стоит сделать ее перевод?