[erlang-questions] Web app back-ends

[Antoine Koener]

To add something to this thread that also exists but seems to be quite
ignored:
Take a look at https://github.com/ztmr/egtm which uses
http://www.fisglobal.com/products-technologyplatforms-gtm.

It's an ACID Schema less store engine (with M language as a really powerful
'stored procedure' engine).

Extract from the website:

The GT.M data model is a hierarchical associative memory (i.e.,
multi-dimensional array) that imposes no restrictions on the data types of
the indexes and the content - the application logic can impose any schema,
dictionary or data organization suited to its problem domain.* GT.M's
compiler for the standard M (also known as MUMPS) scripting language
implements full support for ACID (Atomic, Consistent, Isolated, Durable)
transactions, using optimistic concurrency control and software
transactional memory (STM) that resolves the common mismatch between
databases and programming languages. Its unique ability to create and
deploy logical multi-site configurations of applications provides unrivaled
continuity of business in the face of not just unplanned events, but also
planned events, including planned events that include changes to
application logic and schema.

Worldwide, GT.M is used in multiple industries, including finance, health
care, transportation, manufacturing and others. GT.M supplies the
processing power to the FIS Profile™ enterprise banking application.


And about the proven stability of this tool, you can look at
http://www.fisglobal.com/products-technologyplatforms-gtm-historyofgtm




On Fri, Jun 20, 2014 at 11:01 AM, Aaron J. Seigo <aseigo@REDACTED> wrote:

> On Wednesday, June 18, 2014 17:21:19 Lloyd R. Prentice wrote:
> > postgeSQL
> > - consider when: you want to use a battle-tested relational data store.
>
> battle-tested (aka reliable), yes. there are key/value stores that are also
> pretty reliable, however.
>
> the real benefit (imho) of pgsql is ACID properties combined with
> 'advanced'
> features such as stored procedures / triggers and custom data types.
>
> as for speed, it's a dead-heat with mysql in real-world work loads. this
> has
> been the case for a number of years now, and is generally acknowledged by
> the
> people working on the respective projects.
>
> however, providing ACID properties makes some action unavoidably slower
> than
> straight-up key/value stores that do not offer those properties.
>
> > - reject when: your data needs are more key-value oriented or free
> form/less
> > structured.
>
> these days, that isn't really accurate. others have pointed out that pgsql
> now
> has key/value storage (hstore) and this is getting better in every release.
> heck, it even has a json datatype these days. you can mix and match
> key/value
> data with structured data in the same table, which is pretty interesting.
>
> the real challenge with pgsql for larger applications imho is horizontal
> scalability. not many projects REALLY require that, but for those that do
> pgsql is not the best choice right now.
>
> replication is still a developing feature set within pgsql and perhaps the
> most promising solution is currently a third-party semi-fork called
> Postgres-
> XC:
>
>         http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki
>
> i personally haven't used Postgres-XC in any sort of production env so i
> can't
> vouch for its completeness or how well it meets the claims its developers
> make, but it seems to be on a good track. (esp compared to the
> architecture of
> other solutions in use with pgsql databases)
>
> this is quite similar to how full text indexing ended up making its way
> into
> pgsql: first as third-party enhancements, then eventually (after several
> years)
> folded into pgsql proper. i expect horizontal scalability features to make
> their way into pgsql sometime in the next 5 years, probably based on this
> or
> another 3rd-party pgsql add-on. but right now these features are not part
> of
> pgsql itself and are still in-development.
>
> tl;dr -> horizontal scalability is probably the most significant weak
> point for
> pgsql right now.
>
> p.s. i've written non-trivial applications (inc one or two i'd actually
> call
> "enterprise" apps with a relatively staight face)
>
> --
> Aaron J. Seigo
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140620/fd33e027/attachment.htm>