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 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-datastore-providers.html
>
> On Wed, 25 Sep 2013 17:59:10 -0300
> Douglas Campos <qmx@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev