Elasticsearch ડેટા ટકાઉ રીતે રાખી શકે છે. તેને મુખ્ય ડેટાબેઝ બનાવવો કે નહીં તે નક્કી કરવા પૂછો કે લખાણ નિષ્ફળ જાય કે સાથે થાય ત્યારે કયા વ્યવસાયિક નિયમો સાચા રહેવા જ જોઈએ.
ઓર્ડર સિસ્ટમમાં પ્રોડક્ટ શોધવી અને ખરીદીની ખાતરી કરવી અલગ કામ છે. પહેલામાં શોધની પ્રાસંગિકતા મહત્વની છે; બીજામાં પેમેન્ટ અને સ્ટૉકના ફેરફારો સાચા હોવા જરૂરી છે.
માનો કે ખરીદી માટે ઓર્ડર બનાવવો અને સ્ટૉક ઘટાડવો પડે છે. માત્ર એક કામ સફળ થાય તો શું કરવું તે વ્યવસાયે નક્કી કરવું જોઈએ.
[Create order] ---- must coordinate ---- [Reduce stock]
| |
success failure?
Elasticsearchનું bulk API ઘણી document ક્રિયાઓ સાથે મોકલે છે, પરંતુ એક નિષ્ફળ અને બીજી સફળ થઈ શકે. તે બધું થાય અથવા કશું નહીં થાય એવું transaction નથી બનાવતું. ઍપ્લિકેશને દરેક પરિણામ તપાસવું પડે. Bulk API.
જો ઘણા રેકોર્ડનો ફેરફાર atomic હોવો જરૂરી હોય તો transactional database સામાન્ય રીતે વધુ સીધો આધાર આપે છે. આ સંકલન જાતે બનાવવાથી વધુ નિષ્ફળતાના કિસ્સા અને પુનઃપ્રાપ્તિનું કામ ઉમેરાય છે.
Optimistic concurrency control તપાસે છે કે તમે વાંચેલા વર્ઝન પછી document બદલાયો છે કે નહીં. તે જૂના આધારવાળું update નકારી શકે છે, જેથી એક client બીજાનું કામ ચૂપચાપ overwrite ન કરે. Concurrency control.
આ સુરક્ષા update થતા documentને લાગુ પડે છે. તે stock અને order documentને આપમેળે જોડતી નથી, relational foreign key આપતી નથી કે વ્યવસાયિક fields પર મનગમતા uniqueness નિયમો અમલમાં મૂકતી નથી.
સ્ટોરેજ પસંદ કરતાં પહેલાં જરૂરી નિયમો લખો. તેનાથી નિર્ણય “search engine” કે “database” નામને બદલે ચોક્કસ જરૂરિયાત પર આધારિત બને છે.
સફળ લખાણ અને શોધમાં દેખાતું પરિણામ અલગ ઘટનાઓ છે:
[Write accepted] -> [Refresh] -> [Search can see the change]
Refresh નવા ફેરફારોને search માટે દૃશ્યમાન બનાવે છે. એટલે document IDથી real-time lookup અને search query અલગ છે. refresh=wait_for શોધમાં દેખાય ત્યાં સુધી રાહ જોઈ શકે, પરંતુ multi-document transaction બનાવતું નથી. Refreshનું વર્તન.
પ્રોડક્ટ સર્ચ પેજમાં થોડો વિલંબ સ્વીકાર્ય હોઈ શકે. અંતિમ પેમેન્ટ કે પરવાનગીના નિર્ણય માટે જરૂરી consistency સ્પષ્ટ કરો અને તે આપતો સ્રોત વાંચો. Refresh અને ટકાઉ સંગ્રહ પણ અલગ બાબતો છે.
| જરૂરિયાત | તપાસવાની દિશા | કારણ |
|---|---|---|
| ઓર્ડર અને સંબંધિત રેકોર્ડ atomic રીતે બદલાવા જોઈએ | મુખ્ય transactional database | સાચાપણાના નિયમો authoritative રેકોર્ડની નજીક હોવા જોઈએ. |
| લવચીક full-text search જોઈએ | Elasticsearch શોધની નકલ તરીકે | શોધનો ડેટા અલગ રીતે ગોઠવી અને ફરી બનાવી શકાય. |
| સ્વતંત્ર documents અને અનુકૂળ consistency જરૂરિયાતો | Elasticsearch મુખ્ય store તરીકે યોગ્ય હોઈ શકે | બીજા ડેટાબેઝનો સ્પષ્ટ હેતુ હોવો જોઈએ. |
ઓર્ડર સિસ્ટમની સામાન્ય રચના:
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
authoritative data search copy
CDC committed ફેરફારો પકડે છે; outbox વ્યવસાયિક update સાથે એ જ transactionમાં event નોંધે છે. અલગ પ્રક્રિયા ફેરફારો index સુધી પહોંચાડે છે. આમ બે અસંબંધિત લખાણ હંમેશાં સાથે સફળ થશે એવી ધારણા રાખવી પડતી નથી.
Indexingમાં હજી stable IDs, version handling, deletes, retries અને lag monitoring જરૂરી છે. સ્રોતમાંથી index ફરી બનાવવાની તપાસ કરો. નહીં તો searchની નકલ બીજી અસુસંગત source of truth બની શકે.
ભૂમિકા જે હોય તે, backupનું આયોજન અને restoreની તપાસ કરો. Replica ઉપલબ્ધતા વધારે છે, પરંતુ backupનું સ્થાન લેતું નથી. વાસ્તવિક configuration માટે સ્વીકાર્ય data loss અને recovery time નક્કી કરો.
ઓર્ડરના ઉદાહરણમાં હું transactional રેકોર્ડ તેમના નિયમોને સમર્થન આપતા ડેટાબેઝમાં રાખું અને searchની જરૂરિયાત યોગ્ય ઠેરવે તો Elasticsearch ઉમેરું. સ્વતંત્ર search-oriented documents માટે હું તપાસું કે Elasticsearch એકલું storage, consistency અને recoveryની જરૂરિયાત પૂરી કરે છે કે નહીં.
યાદ રાખો: workloadને જરૂરી ગેરંટી પ્રમાણે પસંદ કરો, પછી failure અને recoveryનું વર્તન તપાસો. Searchની ઝડપ નિર્ણયનો માત્ર એક ભાગ છે.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો