Со стороны фб иск не может быть предъявлен вконтакте ввиду отсутствия у фб прав. Эти права принадлежат компании ConnectU. О чем есть досудебное соглашение между фб и ConnectU.
ConnectU не может предъявить иск вконтакту, потому что Дуров у них ничего не крал. Крал Цукенберг. О чем есть досудебное соглашение между фб и ConnectU.
Вот только бегом на… побежали еще до того как европейские клоны их послали на…
Просто у фб есть одна юридическая проблемка. Для подачи иска по поводу нарушения прав нужно иметь доказательства наличия этих прав. А у фб только одно доказательство — досудебное урегулирование наезда со стороны ConnectU по поводу нарушения прав принадлежащих ConnectU :-)
Так что со стороны фб вконтакте ниче не грозит.
Если только ConnectU не соберется наехать, бабки на адвокатов у них теперь есть.
Опять же Дуров & К у ConnectU ниче не тырил, так что с учетом Российской специфики те наезжать не будут, чтоб на… не ходить.
По производительности для php в свое время бенчмарил.
Аналогичные методы при использовании libmemcached от не хуже до 30% быстрее чем у данги.
mget при выборке 16 ключей приблизительно в 7 — 10 раз делал стандартный get. Если тянуть за раз два ключа — выигрыш процентов 20 получился.
Естественно влияют настройки дистрибуции. Если загнать на предел, MEMCACHED_BEHAVIOR_KETAMA и т.п., set процентов на 15-20 сливал данге, get на 0-10, mget тоже проседал. Правда получаем с другой стороны полноценную кетаму.
class MyMemcached extends Memcached
{
/**
* Сохраняет в кэше сущность от которой зависят остальные
* @param str $byKey тэг
* @param str $key ключ
* @param any $value значение
*/
public function set_and_key($byKey, $key, $value){
// В реале конечно по другому, тут кому как удобнее главное уникальный
if ($this->set($byKey, rand())) // Сохраняем новое уникальное значение для тэга $byKey
return $this->set($key, $value);
return false;
}
/**
* Сохраняет в кэше зависимую сущность, привязав ее к текущему значению тэга
* @param str $byKey тэг
* @param str $key ключ
* @param any $value значение
*/
public function set_by_key($byKey, $key, $value){
return $this->set($this->get($byKey). $key, $value); // Ложим в кэш с ключем привязанным
// к текущему значению тэга
}
/**
* Получает из кэша зависимую сущность
* @param str $byKey
* @param str $key ключ
*/
public function get_by_key($byKey, $key){
return $this->get($this->get($byKey). $key);
}
}
$mc = new MyMemcached;
$mc->addServer('localhost', 11211);
$slaveValue = 'value'; // Значение, которое мы привяжем к $byKey
$mc->set_by_key('byKey', 'slaveValue', $slaveValue); // Сохраняем в кэше
//$slaveValue, привязав его к текущему значению byKey
var_dump($mc->get_by_key('byKey', 'slaveValue')); // Проверяем, что лежит в кэше;
//string(5) «value» — то что положили
$masterValue = 2; // Меняем значение тэга, от которого зависит $slaveValue
$mc->set_and_key('byKey', 'masterValue', $masterValue); // обновляем его значение в кэше
var_dump($mc->get_by_key('byKey', 'slaveValue')); // Пытаемся получить из кэша $slaveValue;
//bool(false) — то что и нужно, тэг изменился
Прогнал. Просто в свое время когда запнулся за них _by_key натолкнуло на мысль как крайне просто контроль зависимостей реализовать. Обертку уже и не помню за час или полтора накидал. Больше про нее и не вспоминал — работает ведь. А в голове почему то отложилось что _by_key использовал.
На коленке упрощенный пример накидал как это реализовано.
Это для pecl.php.net/package/memcached. Для данговского клиента по моему достаточно будет Memcached на Memcache поменять :-(
На больших таблицах к сожалению это уже не так.
Даже если весь индекс лежит в раме.
И на них использование memcached оправданно.
Да и при быстрых запросах, если их много, выигрыш очень серьезный есть. А это снижение нагрузки на базу.
Другой вопрос — обертка может быть сама настолько тяжелой, что съест выигрыш от кэширования.
Ну это уже вопрос используемого API. Стандартное данговское не выдерживает никакой критики по ущербности функционала.
В принципе, libmemcached подкупает тем, что большинство функционала из статьи, в ней реализовано. И если и делать обертку, то предельно простую и соответственно быструю.
В libmemcached понятие _by_key по сути является является аналогом тэга в понимании DmitryKoterov.
И служит именно для управления зависимостями. При этом производительность будет похоже даже не в разы, а на порядки выше и кода меньше.
А какие проблемы.
Если в результате выполнения запроса получается выборка с одним полем — GROPUP_CONCAT на него INTO myvar.
Дальше собрать запрос CONCAT'ом и выполнить.
Если одно значение просто его в переменную.
Если набор строк с несколькими полями, то IMHO лучше на клиента вернуть и там обработать, а по результатам новый запрос отправить. Тут нередко и кэш может помочь.
С темповой таблицей поаккуратнее, она ведь может и на диске образоваться, естественно в самый подходящий момент, в неподходящий, когда нагрузки нет — ей в оперативке места хватит. :)
А я тупой думал, что когда из клиента запрос на сервер шлю — сервер его сначала парсит и только потом выполняет. И вообще сдуру думал, что любой запрос, если он не в хранимой процедуре, для сервера динамический и его парсить надо.
Спасибо за просветление.
Так все таки, вообще нельзя с клиента запросы слать или они пока до сервера доходят волшебным образом парсятся?
Сейчас пытаюсь смотреть в сторону libmemcached tangent.org/
У нее большой плюс — с полпинка завелась в MySQL, через UDF полный доступ ко всем основным функциям.
Есть сомнения по совместимости с организацией кластера memcached в том же PHP.
Можно попробовать что-то вроде
$conn = new Memcache;
if(!$conn->AddServer($ip, $port) and !$conn->pconnect($ip, $port))
throw new Exception(«Memcache connection error»);
ConnectU не может предъявить иск вконтакту, потому что Дуров у них ничего не крал. Крал Цукенберг. О чем есть досудебное соглашение между фб и ConnectU.
Просто у фб есть одна юридическая проблемка. Для подачи иска по поводу нарушения прав нужно иметь доказательства наличия этих прав. А у фб только одно доказательство — досудебное урегулирование наезда со стороны ConnectU по поводу нарушения прав принадлежащих ConnectU :-)
Так что со стороны фб вконтакте ниче не грозит.
Если только ConnectU не соберется наехать, бабки на адвокатов у них теперь есть.
Опять же Дуров & К у ConnectU ниче не тырил, так что с учетом Российской специфики те наезжать не будут, чтоб на… не ходить.
Аналогичные методы при использовании libmemcached от не хуже до 30% быстрее чем у данги.
mget при выборке 16 ключей приблизительно в 7 — 10 раз делал стандартный get. Если тянуть за раз два ключа — выигрыш процентов 20 получился.
Естественно влияют настройки дистрибуции. Если загнать на предел, MEMCACHED_BEHAVIOR_KETAMA и т.п., set процентов на 15-20 сливал данге, get на 0-10, mget тоже проседал. Правда получаем с другой стороны полноценную кетаму.
class MyMemcached extends Memcached
{
/**
* Сохраняет в кэше сущность от которой зависят остальные
* @param str $byKey тэг
* @param str $key ключ
* @param any $value значение
*/
public function set_and_key($byKey, $key, $value){
// В реале конечно по другому, тут кому как удобнее главное уникальный
if ($this->set($byKey, rand())) // Сохраняем новое уникальное значение для тэга $byKey
return $this->set($key, $value);
return false;
}
/**
* Сохраняет в кэше зависимую сущность, привязав ее к текущему значению тэга
* @param str $byKey тэг
* @param str $key ключ
* @param any $value значение
*/
public function set_by_key($byKey, $key, $value){
return $this->set($this->get($byKey). $key, $value); // Ложим в кэш с ключем привязанным
// к текущему значению тэга
}
/**
* Получает из кэша зависимую сущность
* @param str $byKey
* @param str $key ключ
*/
public function get_by_key($byKey, $key){
return $this->get($this->get($byKey). $key);
}
}
$mc = new MyMemcached;
$mc->addServer('localhost', 11211);
$masterValue = 1;
$mc->set_and_key('byKey', 'masterValue', $masterValue);
$slaveValue = 'value'; // Значение, которое мы привяжем к $byKey
$mc->set_by_key('byKey', 'slaveValue', $slaveValue); // Сохраняем в кэше
//$slaveValue, привязав его к текущему значению byKey
var_dump($mc->get_by_key('byKey', 'slaveValue')); // Проверяем, что лежит в кэше;
//string(5) «value» — то что положили
$masterValue = 2; // Меняем значение тэга, от которого зависит $slaveValue
$mc->set_and_key('byKey', 'masterValue', $masterValue); // обновляем его значение в кэше
var_dump($mc->get_by_key('byKey', 'slaveValue')); // Пытаемся получить из кэша $slaveValue;
//bool(false) — то что и нужно, тэг изменился
На коленке упрощенный пример накидал как это реализовано.
Это для pecl.php.net/package/memcached. Для данговского клиента по моему достаточно будет Memcached на Memcache поменять :-(
Даже если весь индекс лежит в раме.
И на них использование memcached оправданно.
Да и при быстрых запросах, если их много, выигрыш очень серьезный есть. А это снижение нагрузки на базу.
Другой вопрос — обертка может быть сама настолько тяжелой, что съест выигрыш от кэширования.
Ну это уже вопрос используемого API. Стандартное данговское не выдерживает никакой критики по ущербности функционала.
В принципе, libmemcached подкупает тем, что большинство функционала из статьи, в ней реализовано. И если и делать обертку, то предельно простую и соответственно быструю.
А mget там — это вообще ракета.
Именно поэтому вопрос и возник.
В libmemcached понятие _by_key по сути является является аналогом тэга в понимании DmitryKoterov.
И служит именно для управления зависимостями. При этом производительность будет похоже даже не в разы, а на порядки выше и кода меньше.
Советую почитать
tangent.org/
pecl.php.net/package/memcached
Может проще и однозначно с большей производительностью задействовать механизм _by_key из libmemcached?
Если в результате выполнения запроса получается выборка с одним полем — GROPUP_CONCAT на него INTO myvar.
Дальше собрать запрос CONCAT'ом и выполнить.
Если одно значение просто его в переменную.
Если набор строк с несколькими полями, то IMHO лучше на клиента вернуть и там обработать, а по результатам новый запрос отправить. Тут нередко и кэш может помочь.
С темповой таблицей поаккуратнее, она ведь может и на диске образоваться, естественно в самый подходящий момент, в неподходящий, когда нагрузки нет — ей в оперативке места хватит. :)
А я тупой думал, что когда из клиента запрос на сервер шлю — сервер его сначала парсит и только потом выполняет. И вообще сдуру думал, что любой запрос, если он не в хранимой процедуре, для сервера динамический и его парсить надо.
Спасибо за просветление.
Так все таки, вообще нельзя с клиента запросы слать или они пока до сервера доходят волшебным образом парсятся?
если не поможет Вам сюда
enterview.ru/interview/19/
Типа конкуренция между двумя отделами одной конторы.
www.lastfm.ru/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients
не впечатлила.
Сейчас пытаюсь смотреть в сторону libmemcached
tangent.org/
У нее большой плюс — с полпинка завелась в MySQL, через UDF полный доступ ко всем основным функциям.
Есть сомнения по совместимости с организацией кластера memcached в том же PHP.
Можно конечно привинтить ее в PHP
labs.gree.jp/Top/OpenSource/libmemcached-en.html
Смущает номер версии 0.1.0 и шалашики.
$conn = new Memcache;
if(!$conn->AddServer($ip, $port) and !$conn->AddServer($ip, $port))
throw new Exception(«Memcache connection error»);
Здесь способ борьбы с ним
david-m.livejournal.com/993877.html
Можно попробовать что-то вроде
$conn = new Memcache;
if(!$conn->AddServer($ip, $port) and !$conn->pconnect($ip, $port))
throw new Exception(«Memcache connection error»);
Было бы интересно узнать результат.
Результат — полный ступор :-(
После трехминутного КМБ все, что им нужно от браузера, стало понятно, очевидно и просто. :-)
Но попросили IE вернуть обратно, привычный :-(
На аргументы удобнее, быстрее, проще и т.п. ответ был до до боли знакомый. Оно и так делает все что надо и всякие там нам не надо.
IMHO.
Отгрызать будет, и сильно, у FF и оперы.
У IE очень медленно.