Подскажите мне такую штуку...

← →
Kerk © (2009-12-07 00:45) [0]

Сейчас попробую описать. Смотрю я сейчас в сторону memcached и xcache (это чтоб понятнее было о чем речь). Но они хранят в памяти пару ключ-значение, а мне нужно ключ-массив значений.

Понятно, что можно в качестве значения в memcached хранить некие данные, которые руками разгребать как массив. Но мне еще нужно из этих массивов данные удалять и в них добавлять. Если я все это буду делать руками, то боюсь, есть риск рассинхронизации данных (ибо конечно не один процесс занимается изменениями).

Есть такие решения?

← →
wicked © (2009-12-07 00:46) [1]

> Есть такие решения?

serialize/unserialize

ЗЫ ты ж про пхп спросил?

← →
KilkennyCat © (2009-12-07 00:47) [2]

разве memcached не массив?

← →
Kerk © (2009-12-07 00:49) [3]

> wicked © (07.12.09 00:46) [1]

Вообще да, но это не важно.
Я не понимаю как эти две функции решат такую проблему:

1) 1 процесс берет данные, удаляет один элемент
2) 2 процесс берет данные, добавляет 3 элемента
3) 2 процесс записывает обновление в соответствии с ключом в memcached
4) 1 процесс записывает свое обновление

Таким образом мы теряем те добавленные 3 элемента.

← →
Kerk © (2009-12-07 00:50) [4]

> KilkennyCat © (07.12.09 00:47) [2]
> разве memcached не массив?

Я мож чего не понимаю, но memcached можно сравнить с одномерным массивом (ключ значение), а мне надо двумерный (ключ - много значений).

← →
KilkennyCat © (2009-12-07 00:52) [5]

а. понял. не знаю :(

← →
wicked © (2009-12-07 00:55) [6]

> Я не понимаю как эти две функции решат такую проблему:
>
> 1) 1 процесс берет данные, удаляет один элемент
> 2) 2 процесс берет данные, добавляет 3 элемента
> 3) 2 процесс записывает обновление в соответствии с ключом
> в memcached
> 4) 1 процесс записывает свое обновление

тут или СУБД поможет (неожиданно, правда?), или если брать ссылки на элементы, а не сами элементы

хотя со ссылками сможет работать если только все манипуляции будут в 1 процессе происходить

иначе, по логике, никак

---
пока писал, придумал еще 2 варианта
1 - сложный ключ, который будет включать в себя и ссылки на субэелементы

2 - двухуровневая структура - на 1 уровне ключи ссылаются на ключики для элементов, на 2-м - ключики для элементов содержат данные

и вообще, тебе про NoSQL читать - http://en.wikipedia.org/wiki/NoSQL - это вроде оно

← →
Kerk © (2009-12-07 01:10) [7]

Ну СУБД - самый в лоб вариант. Просто хранить мне все это нафиг не надо, достаточно в памяти держать. Потому и стал думать о каких-то более легковесных вариантах решения задачи.

← →
KilkennyCat © (2009-12-07 01:19) [8]

На хабрахабре читал? Я недавно видел там кучку статей на тему мемкеша.

Вот нашел что-то близкое. Изучаю.
http://habrahabr.ru/blogs/webdev/43539/

http://code.google.com/p/memcached-tag/

> 1) 1 процесс берет данные, удаляет один элемент
> 2) 2 процесс берет данные, добавляет 3 элемента
> 3) 2 процесс записывает обновление в соответствии с ключом
> в memcached
> 4) 1 процесс записывает свое обновление

п.4 - не выполнится. Записывать не куда, хэша к массиву 1го процесса уже не существует, и найти массив можно только перебором.

> п.4 - не выполнится. Записывать не куда, хэша к массиву
> 1го процесса уже не существует, и найти массив можно только
> перебором.

Ляпнул не разобравшись с вопросом.
Если ключ постоянный, то 4 конечно сработает.

Подскажите мне такую штуку... Найти похожие ветки