Key-value db vs relational

<p>Hello. I am trying to create a website similar to LinkedIn where a user can search for the candidate based on the criteria. (I.e. Location=Boston, age=25&lt;x&lt;35, computer skill=9)</p> <p>I&#39;d like to use key value db, however it seems very difficult as there are many possible combination of queries. </p> <p>Am I missing or lack of knowledge on key value? Or, in this case, relational would be the choice? (Assume there will be huge number of records)</p> <p>Thank you</p> <hr/>**评论：**<br/><br/>schoenobates: <pre><p>Personally, I would use a relational DB or document store for this use case. KV stores are great, but they tend to suit use cases where fast retrieval is more important than complex querying: this is their trade off - fast retrieval at the cost of simpler data management and/or query capability. </p> <p>My recommendation would be Postgres combined with pgx (<a href="https://github.com/jackc/pgx" rel="nofollow">https://github.com/jackc/pgx</a>). PG can scale up very well and there are solutions to scale horizontally as well, however, I imagine it will be a while for any company before they reach that kind of level.</p> <p>HTH</p></pre>gonyyi: <pre><p>Thank you! I definitely look into Postgres and PGX! Have a good day!</p></pre>schoenobates: <pre><p>No worries :) Just to follow up on what <a href="/u/tvmaly" rel="nofollow">/u/tvmaly</a> commented, HStore is a solid extension to Postgres, but the new JSONB functionality is just awesome and you get the full JSON types rather than just strings. The newly released 9.5 version has added some extra JSONB features.</p> <p><a href="http://www.postgresql.org/docs/current/static/hstore.html" rel="nofollow">http://www.postgresql.org/docs/current/static/hstore.html</a> <a href="http://www.postgresql.org/docs/9.5/static/functions-json.html" rel="nofollow">http://www.postgresql.org/docs/9.5/static/functions-json.html</a></p> <p>Both are supported by PGX very nicely.</p></pre>gonyyi: <pre><p>Great!! Thank you so much! I now know which direction I will head.</p></pre>BoTuLoX: <pre><p>Do I assume correctly that pgx can be used as a drop-in replacement to pg and that it will work well with sqlx?</p></pre>schoenobates: <pre><p>PGX does support the standard SQL packages as well using the package github.com/jackc/pgx/stdlib. I&#39;ve never used sqlx I&#39;m afraid so can&#39;t comment on whether it works or not: sorry!</p></pre>ChristophBerger: <pre><p>What kind of difficulty are you facing?</p> <p>Maybe you do not need a SQL DB but just a different KVDB whose query language better supports your requirements.</p></pre>gonyyi: <pre><p>Thank you. Well, the problem is complexity of query. If it was a simple stuff, I guess I will solve the problem with the key. However, here&#39;s the case:</p> <ol> <li>Location=Boston, age&lt;35, computer skill=9</li> <li>Computer skill = 9, Golang=True, Java=True</li> <li>Location=Dallas,Java=True,Computer skill&gt;5</li> </ol> <p>There are so many different possibilities, and I am wondering if I need to create all the keys for each possible cases. </p> <p>Thank you</p></pre>tvmaly: <pre><p>I started with a key value store ( Redis and Boltdb ) for my food project ( bestfoodnearme.com ). I was originally going to use postgresql, but I did not know what my schema would look like. So in this case key value was easier to get started with. In the long run, I would recommend moving to a relational db. You could always use the key value store in postgresql ( hbase )</p></pre>gonyyi: <pre><p>Thank you! I will look into Postgres! </p></pre>jayposs: <pre><p>A db with powerful query capability (like Postgres) probably does make the most since, but I was thinking ... </p> <p>Looks like you may have 1 table with lots of records and many records having the same values (ex. Java=True). Should you index all the search fields ? If not, I think the database will have to read every record for every query. Will these indexes cause any problems ? </p> <p>With something like Bolt, you can segregate data into buckets. For example, a Golang bucket that contains candidate ids that have Go. Of course you could have separate tables in the sql solution as well. </p> <p>I&#39;m sure figuring this all out can get complicated, but there may be multiple good solutions.</p></pre>freedsnout: <pre><p>If you would rather use a non-relational database, I would suggest trying a document store rather than a key-value store. i.e. MongoDB.</p></pre>gonyyi: <pre><p>Thank you, in that case, how can I handle queries with potentially hundreds of combination? I am relatively new to KVDB, and having a hard time thinking.</p></pre>BoTuLoX: <pre><p>If you&#39;re doing non-trivial queries, you do not want a non-relational databse.</p> <p>If your data has relations, you use a relational database.</p></pre>