<p dir="ltr">Hi,<br>
Sharing a nice article on postgresql and jsonb...<br>
<a href="http://obartunov.livejournal.com/193870.html">http://obartunov.livejournal.com/193870.html</a><br></p>
<p dir="ltr">"Envoyé depuis mon mobile " Eric</p>
<br><br>---- Jesper Louis Andersen a écrit ----<br><br><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Mar 23, 2017 at 10:51 PM Danniel Condez <<a href="mailto:ducondez@gmail.com">ducondez@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">Hi,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Any recommendation for persisting a Map into an unstructured db/filesystem. The goal is to store and fetch it as is, so that both erlang backend and FrontEnd (GraphQL) can easily fetch it.<br class="gmail_msg"></div><br class="gmail_msg"></div></blockquote><div><br></div><div>Our GraphQL system uses Postgres as a database and utilizes jsonb columns to store map data inside the database. The tradeoff is that your map keys are binary(), but the advantage is that you have the ability to add indexes over your jsonb columsn for quicker access to report-style queries in your data set.<br><br></div><div>We essentially took Facebook's TAO-paper (Types, Associations & Objects) and implemented it on top of Postgres rather than MySQL. We can then use the TAO-API in order to satisfy queries in the GraphQL system. Preliminary analysis and benchmarking shows that this works exceptionally well. Most queries are satisfied by index lookups from memory and is in the sub 3ms range, even for larger blobs of data.<br><br></div><div>Our current primary gotcha is that you can't define<br><br></div><div>-spec m() :: #{ <<"foo">> := integer(), <<"bar">> := integer() }.<br><br></div><div>for the dialyzer. So we can't make the dialyzer efficient at debugging right now. However, the keys are static keys, so we could probably convert them into atom()'s without too much hassle. They are limited in what they can be. This requires some future rework of our GraphQL layer as well though.<br><br></div><div>(For those interested in the GraphQL stuff: talk and release is currently slated for EUC 2017). <br></div></div></div>