Sorry for my late reply to this thread, I've was side tracked with a few
other issues but I'm back on track now.
I don't have much to report at the moment except to share the branch we are
working on for the different database options, and how to run/configure
them if anyone would like to try them out.
We are currently looking into what store will be the best fit for our
SimplePush Server and are trying three types of databases, MySql (JPA),
Redis, and CouchDB in this
.
Using the above branch one can try the different database by making changes
to the AS7/WildFly configuration (standalone.xml in most cases).
For example, to use a JPA database one would use:
<subsystem xmlns="urn:org.jboss.aerogear.simplepush:1.0">
<server socket-binding="simplepush" token-key="changeMe!"
notification-tls="false" sockjs-tls="false">
<datastore>
<jpa
datasource-jndi-name="java:jboss/datasources/SimplePushDS"
persistence-unit="SimplePushPU"/>
</datastore>
</server></subsystem>
To use Redis:
<subsystem xmlns="urn:org.jboss.aerogear.simplepush:1.0">
<server socket-binding="simplepush" token-key="changeMe!"
notification-tls="false" sockjs-tls="false">
<datastore>
<redis host="localhost" port="6379"/>
</datastore>
</server></subsystem>
To use CouchDB:
<subsystem xmlns="urn:org.jboss.aerogear.simplepush:1.0">
<server socket-binding="simplepush" token-key="changeMe!"
notification-tls="false" sockjs-tls="false">
<datastore>
<couchdb url="http://127.0.0.1:5984"
database-name="simplepush"/>
</datastore>
</server></subsystem>
I'm writing a gist describing how data is stored with Redis and CouchDB and
will post back here when it's done to get feedback.
On 26 September 2013 17:15, JR Conlin <jrconlin(a)gmail.com> wrote:
I'm not familiar with Hibernate, but I'm a HUGE advocate of
abstraction
at functional levels. (e.g. classic MVC designs). Generally, what's good
today may not be good tomorrow, and having unencumbered interfaces lets
you swap in what makes the most amount of sense with the least impact to
your code.
The nice thing about Key/value is that you've got the most amount of
flexibility around what you actually use to store data; Postgres, MySQL,
Redis, Memcache, heck an in memory hash can all do it.
As for which data store you actually use, that's kinda driven by what
you expect your load to be. If you're only talking a few thousand
clients with a dozen channels, each getting an update when a flights
status changes, then you're not talking about putting a huge strain on
your storage or it's Read/Write capacity. If you've got a few hundred
million clients and some partners who've decided to use your system as
part of their FPS game updates, then you've got lots more problems.
(And now you start to understand why I wake up in a cold sweat screaming
about how you don't use SimplePush for real time stock quotes.)
On 2013/9/26 2:50 AM, Karel Piwko wrote:
> No reason to push for Mongo then, my experience with NoSQL databases (not
> counting XML databases) is pretty limited and I'm glad you gave me some
insight.
>
> What about abstraction layer idea based on Hibernate OGM? Does it make
any
> sense to you? Currently is does support only Infinispan, EHCache and
MongoDB
> [1], so I guess it's out of question as well.
>
> Karel
>
>
> [1]
>
http://docs.jboss.org/hibernate/ogm/4.0/reference/en-US/html/ogm-datastor...
>
> On Wed, 25 Sep 2013 17:59:10 -0300
> Douglas Campos <qmx(a)qmx.me> wrote:
>
>> On Wed, Sep 25, 2013 at 09:53:19AM -0700, JR Conlin wrote:
>>> The concern with using Mongo is that it's very lossy and fairly
>>> unreliable as a data store for a number of reasons. (It's fine for
>>> simple, low demand systems, but has complications once you really start
>>> to hammer on it.)
>>>
>>>
http://blog.schmichael.com/2011/11/05/failing-with-mongodb/
>>>
http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb
>>> etc.
>>>
>>> I'd suggest sticking with other DBs unless you're ok with loss or
don't
>>> plan on heavily exercising it.
>> Seconded, have had severe data loss with mongo under high load at my
>> previous job
>>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev