[cookiemonster6667]

Just throw some ideas, is it viable to build tables for elements of people search, for example, name table, address table, email table, phone table,  companies table,  etc. then just link the related records.?  Because one person usually has multiple phone/email/addresses/companies, this method might be neater than having multiple records for one person. Meanwhile, it will be lots of work to prepare existing leaked dbs into this format.  

Or it's easier to just dump everything into elasticsearch?

What will be the cost/efficiency comparasion?
What's the common practice for existing people search service?

I am a newbie here. Any input is appreciated!

This forum account is currently banned. Ban Length: Permanent (N/A Remaining)
Ban Reason: Mass Leeching | https://breachforums.rs/Forum-Ban-Appeals if you feel this is incorrect.

[joepa]

Depends on the size. Search engine like Elastic is probably faster for really large datasets. A relational SQL DB is probably good enough for everything else.

[notagh0st]

As @joepa said, it depends on the size and how you want to store the data. Is all of the data going to be extracted at rest? Or will it be compressed at rest, and only extracted when being queried? Some of the databases I would look at would be Apache Solr: https://solr.apache.org/ Elastic Search: https://www.elastic.co/elasticsearch/ and Cassandra: https://cassandra.apache.org/_/index.html

All of these are widely used by big companies with extremely large datasets (Facebook, Netflix, Amazon, etc.)

Edit: But if you're not dealing will millions, tens-of-millions of records, you're going to be just fine to use a normal relational database like Postgres, MySQL, etc. NoSQL databases like MongoDB would also work just fine with this level of records.