Асинхронный доступ к базе данных с помощью EventMachine - PullRequest
Новая
       1

Асинхронный доступ к базе данных с помощью EventMachine

2 голосов
/ 10 марта 2011

Я начал работу над простым проектом EventMachine, чтобы принимать данные от набора сетевых клиентов, записывать их в базу данных и одновременно отправлять их разным наборам клиентов.Клиентская часть клиента A => B - это то, что реактор делает сумасшедшим легким, но доступ к базе данных не такой большой - по крайней мере, неблокирующим, равномерным способом.Я пытался найти приличный ORM, который поддерживает асинхронный доступ таким образом, чтобы он хорошо работал с EventMachine, и в то же время предоставлял все абстракции ORM, которые я знаю и люблю - я надеюсь не открывать кучу сокетов и не обсуждать SQLих!Кроме того, желательно поддерживать разумное распространение поддержки БД (я видел пару статей, объясняющих, как заставить асинхронную ActiveRecord работать, например, только с mysql).

Пока что все, что я нашел, это swift , которое выглядит так, как будто оно должно сработать, но кажется довольно минимальным по сравнению с вашими ActiveRecord и DataMappers.

Есть ли еще какие-нибудь пути, по которым стоит здесь идти?Возможно, одна из главных электростанций ORM имеет малоизвестную асинхронную ветвь?: P

Ответы [ 2 ]

2 голосов
/ 08 мая 2012

согласен, как говорит Грегори, если вы можете использовать собственные адаптеры, которые поддерживают асинхронные операции - используйте их. У mysql2 & pg gems довольно хорошая асинхронная поддержка.

В качестве примечания, swift (заявление об отказе: я соавтор) выполнил некоторую работу по очистке API, чтобы упростить асинхронные сценарии использования. Вы можете найти это удобным. 

require 'swift/synchrony'

EM.run do
  3.times.each do |n|
    EM.synchrony do
      db     = Swift.setup(:default, Swift::Adapter::Postgres, db: "swift")
      result = db.execute("select pg_sleep(3 - #{n}), #{n + 1} as qid")

      p result.first
      EM.stop if n == 0
    end
  end
end
2 голосов
/ 10 марта 2011

Лично я предпочитаю использовать драйверы БД непосредственно на серверах на базе EM.

Причина этого заключается в том, что типы проектов, для которых требуются EM-серверы, также требуют высокой производительности, но довольно минимального объема обработки. Таким образом, часто проще собрать несколько операторов SQL, чем правильно настроить ORM и заставить его работать с EM.

С ORM, особенно продвинутым, слишком легко представить какое-то узкое место. Кроме того, EM по-прежнему не очень широко распространен, поэтому вероятность появления какой-то странной ошибки больше, если вы попытаетесь использовать ORM поверх простого драйвера.

Mysql2 gem имеет встроенную поддержку асинхронных операций. Postgresql Я не использовал в последнее время, так что не уверен.

...