sql >> Databasteknik >  >> RDS >> Mysql

Databas för fulltextsökning och 200 miljoner+ poster

Jag tror att att hålla primära poster i en SQL-databas och duplicera dem till en noSQL-databas är ett mycket vanligt tillvägagångssätt.

ElasticSearch har en pågående statussida om deras resiliency . Även i den senaste versionen kan ElasticSearch tappa data i ett antal olika situationer . En stor förändring i strukturen för ett ElasticSearch-index (som att lägga till analysatorer) kräver att du indexera om alla dokument. Denna process är säkrare om du har en annan källa för dokumenten. I slutändan är ElasticSearch inte utformat för att konsekvent lagra dokument - jag skulle bara någonsin välja att använda ElasticSearch som den primära butiken i situationer där tillfällig dataförlust inte är en katastrof.

Till skillnad från ElasticSearch är MongoDB utformad för att vara fjädrande . Du bör säkert kunna lagra dokument i MongoDB. Jag har upptäckt att det kan vara lite smärtsamt att försöka göra fulltextsökningar i MongoDB, åtminstone jämfört med ElasticSearch. Enligt min åsikt, för textsökning, är den enda fördelen MongoDB har jämfört med MySQL:s FULLTEXT är att den delas ut.

Vi kör ElasticSearch och MySQL just nu - och fördelarna uppväger avsevärt besvären med extra infrastruktur och att hantera replikering mellan de två. Vi hade tidigare försökt använda en noSQL-lösning som primär datalagring, med katastrofala resultat. Att köra en ES i kombination med en MySQL ger dig det bästa av två världar - konsistens och säkerhet för data i SQL, med den skalbara, effektiva fulltextsökningen i ES.



  1. MySQL lagrad procedur för att skapa användare

  2. Kontrollera om användarnamnet finns PDO

  3. MYSQL DBDump-felmeddelande

  4. Alternativ till massor av booleans i MySQL?