Хранение данных в memcache для доступа к разным языкам - PullRequest
1 голос
/ 30 сентября 2011

Я работаю в системе, в которой компоненты написаны на следующих языках:

  • C
  • C ++
  • C #
  • PHP
  • Python

Все эти компоненты используют (нечасто изменяющиеся) данные, поступающие из одного и того же источника, которые можно кэшировать и получать из memcache по соображениям производительности.

Поскольку разные типы данных могут по-разному храниться в разных языковых API для memcache, мне интересно, будет ли лучше хранить ВСЕ данные в виде строки (объекты будут храниться в виде строки JSON).

Однако это само по себе может создавать проблемы, поскольку строки (почти наверняка) будут иметь разные внутренние представления на разных языках, поэтому мне интересно, насколько мудрым является это решение.

Кроме того, я использую писателя 1, «шаблон» для нескольких читателей, поэтому параллелизм не является проблемой.

Может ли кто-нибудь (желательно с АКТУАЛЬНЫМ опытом создания чего-то подобного) посоветовать наилучший формат / способ хранения данных в memcache, чтобы их могли использовать разные языки программирования?

Ответы [ 3 ]

3 голосов
/ 30 сентября 2011

memcached Я думаю, что в первую очередь понимает только byte [], и представление байта одинаково во всех языках.Вы можете сериализовать свои объекты, используя протокол буфера или подобную библиотеку, и использовать ее на любом другом языке.Я делал это в своих проектах.

1 голос
/ 30 сентября 2011

Независимо от выбранной серверной части (memcached, mongodb, redis, mysql, почтовый голубь) наиболее быстродействующим способом хранения данных в нем будет простой блок данных (поэтому серверная часть не знает из этого.) Является ли это string, byte[], BLOB, на самом деле все то же самое.

Каждому языку потребуется согласованный механизм для преобразования объектов в сохраняемый формат данных и обратно. Вы:

  • Не стоит создавать свой собственный механизм, это просто изобретать колесо.
  • Следует подумать о том, могут ли «недействительные» объекты оказаться в бэкэнде. (либо из-за ошибки в писателе, либо из-за того, что объекты из предыдущей ревизии все еще присутствуют)

Когда дело доходит до выбора формата, я рекомендую два: JSON или Буферы протокола . Это связано с тем, что их кодированный размер и скорость кодирования / декодирования являются одними из самых маленьких / самых быстрых из всех доступных кодировок.

Сравнение

JSON:

  • Библиотеки доступны для десятков языков, иногда являются частью стандартной библиотеки.
  • Очень простой формат - удобочитаемый при хранении, удобочитаемый!
  • Не требуется согласование между различными системами, просто соглашение о структуре объекта.
  • Не требуется настройка на многих языках, например, PHP: $data = json_encode($object); $object = json_decode($data);
  • Нет встроенной схемы, поэтому читатели должны проверять декодированные сообщения вручную.
  • Занимает больше места, чем буфер протокола.

Буферы протокола:

  • Инструменты для генерации на нескольких языках.
  • Минимальный размер - трудно победить.
  • Заданная схема (внешне) через .proto файлы.
  • Автоматически сгенерированные объекты интерфейса для кодирования / декодирования, например C ++: person.SerializeToOstream(&output);
  • Поддержка различных версий схем объектов для добавления новых optional членов, так что существующие объекты не обязательно становятся недействительными.
  • Не читабельно и не доступно для записи, поэтому, возможно, сложнее в отладке.
  • Определенная схема вводит некоторые накладные расходы на управление конфигурацией.

Unicode

Когда дело доходит до поддержки Unicode, обе справляются с этим без проблем:

  • JSON: Обычно в строке экранируются не-ascii-символы как \uXXXX, поэтому проблем с совместимостью нет. В зависимости от библиотеки может также быть возможным принудительное кодирование UTF-8.
  • Протоколные буферы. Кажется, что используется UTF-8, хотя я не нашел информации в документации Google в 3 фута высотой букв по этому поводу.

Резюме

То, с чем вы пойдете, будет зависеть от того, как именно ваша система будет вести себя, как часто происходят изменения в структуре данных и как все вышеперечисленные пункты повлияют на вас.

0 голосов
/ 30 сентября 2011

Не собираясь лгать, ты мог бы сделать это в Redis. Redis - это база данных значений ключей, написанная для обеспечения высокой производительности и позволяющая передавать данные между языками с использованием ряда различных клиентских библиотек это клиентские библиотеки Вот пример в javaи python

Edit 1: код не проверен.Если вы заметили ошибку, пожалуйста, дайте мне знать:)

Редактировать 2: Я знаю, что я не использовал предпочтительный клиент Redis для Java, но точка зрения остается в силе.

Python

import redis
r = redis.Redis()
r.set('test','123')

Java

import org.jredis.RedisException;
import org.jredis.ri.alphazero.JRedisClient;
import static org.jredis.ri.alphazero.support.DefaultCodec.*;

class ExampleCode{
    private final JRedisClient client = new JRedisClient();
    public static void main(String[] args) throws RedisException {
        System.out.println(toStr(client.get('test')))
    }
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...