DBA બોટ જૉ. એનાટોલી સ્ટેન્સલર (Postgres.ai)

બેકએન્ડ ડેવલપર કેવી રીતે સમજે છે કે SQL ક્વેરી “prod” પર સારી રીતે કામ કરશે? મોટી અથવા ઝડપથી વિકસતી કંપનીઓમાં, દરેકને "ઉત્પાદન" ની ઍક્સેસ હોતી નથી. અને ઍક્સેસ સાથે, બધી વિનંતીઓ પીડારહિત રીતે તપાસી શકાતી નથી, અને ડેટાબેઝની નકલ બનાવવામાં ઘણીવાર કલાકો લાગે છે. આ સમસ્યાઓ ઉકેલવા માટે, અમે એક કૃત્રિમ DBA બનાવ્યું - જૉ. તે પહેલાથી જ ઘણી કંપનીઓમાં સફળતાપૂર્વક લાગુ કરવામાં આવ્યું છે અને એક ડઝનથી વધુ વિકાસકર્તાઓને મદદ કરે છે.

વિડિઓ:

કેમ છો બધા! મારું નામ એનાટોલી સ્ટેન્સલર છે. હું એક કંપનીમાં કામ કરું છું postgres.ai. અમે વિકાસકર્તાઓ, DBAs અને QAs તરફથી Postgres ના કામ સાથે સંકળાયેલા વિલંબને દૂર કરીને વિકાસ પ્રક્રિયાને ઝડપી બનાવવા માટે પ્રતિબદ્ધ છીએ.

અમારી પાસે મહાન ગ્રાહકો છે અને આજે અહેવાલનો ભાગ એવા કિસ્સાઓને સમર્પિત કરવામાં આવશે જે અમે તેમની સાથે કામ કરતી વખતે મળ્યા હતા. અમે તેમને ગંભીર સમસ્યાઓ ઉકેલવામાં કેવી રીતે મદદ કરી તે વિશે હું વાત કરીશ.

જ્યારે આપણે જટિલ હાઇ-લોડ સ્થળાંતર વિકસાવી રહ્યા છીએ અને કરી રહ્યા છીએ, ત્યારે આપણે આપણી જાતને પ્રશ્ન પૂછીએ છીએ: "શું આ સ્થળાંતર શરૂ થશે?". અમે સમીક્ષાનો ઉપયોગ કરીએ છીએ, અમે વધુ અનુભવી સાથીદારો, DBA નિષ્ણાતોના જ્ઞાનનો ઉપયોગ કરીએ છીએ. અને તેઓ કહી શકે છે કે તે ઉડશે કે નહીં.

પરંતુ કદાચ તે વધુ સારું રહેશે જો આપણે તેને પૂર્ણ કદની નકલો પર જાતે ચકાસી શકીએ. અને આજે આપણે ફક્ત તે વિશે વાત કરીશું કે હવે પરીક્ષણ માટેના કયા અભિગમો છે અને તે કેવી રીતે વધુ સારી રીતે અને કયા સાધનો સાથે કરી શકાય છે. અમે આવા અભિગમોના ફાયદા અને ગેરફાયદા વિશે પણ વાત કરીશું, અને અમે અહીં શું ઠીક કરી શકીએ છીએ.

કોણે ક્યારેય ઉત્પાદન પર સીધા જ ઇન્ડેક્સ બનાવ્યા છે અથવા કોઈ ફેરફાર કર્યા છે? તદ્દન થોડી. અને કોના માટે આ હકીકત તરફ દોરી ગયું કે ડેટા ખોવાઈ ગયો હતો અથવા ડાઉનટાઇમ હતો? પછી તમે આ પીડા જાણો છો. ભગવાનનો આભાર ત્યાં બેકઅપ્સ છે.

પ્રથમ અભિગમ ઉત્પાદનમાં પરીક્ષણ છે. અથવા, જ્યારે કોઈ વિકાસકર્તા સ્થાનિક મશીન પર બેસે છે, ત્યારે તેની પાસે ટેસ્ટ ડેટા હોય છે, ત્યાં અમુક પ્રકારની મર્યાદિત પસંદગી હોય છે. અને અમે ઉત્પાદન માટે રોલ આઉટ કરીએ છીએ, અને અમને આ પરિસ્થિતિ મળે છે.

તે દુઃખ આપે છે, તે ખર્ચાળ છે. તે કદાચ શ્રેષ્ઠ નથી.

અને તે કરવાની શ્રેષ્ઠ રીત કઈ છે?

ચાલો સ્ટેજીંગ લઈએ અને ત્યાં પ્રોડનો અમુક ભાગ પસંદ કરીએ. અથવા શ્રેષ્ઠ રીતે, ચાલો એક વાસ્તવિક ઉત્પાદન લઈએ, તમામ ડેટા. અને અમે તેને સ્થાનિક રીતે વિકસાવ્યા પછી, અમે સ્ટેજિંગ માટે પણ તપાસ કરીશું.

આ અમને કેટલીક ભૂલોને દૂર કરવાની મંજૂરી આપશે, એટલે કે તેમને ઉત્પાદન પર રહેવાથી અટકાવશે.

શું સમસ્યાઓ છે?

• સમસ્યા એ છે કે અમે આ સ્ટેજીંગ સહકર્મીઓ સાથે શેર કરીએ છીએ. અને ઘણી વાર એવું બને છે કે તમે કોઈ પ્રકારનો ફેરફાર કરો છો, બેમ - અને ત્યાં કોઈ ડેટા નથી, કામ ડ્રેઇન ડાઉન છે. સ્ટેજીંગ મલ્ટિ-ટેરાબાઈટ હતું. અને તે ફરીથી વધવા માટે તમારે લાંબો સમય રાહ જોવી પડશે. અને અમે આવતીકાલે તેને અંતિમ સ્વરૂપ આપવાનું નક્કી કરીએ છીએ. બસ, આપણી પાસે વિકાસ છે.
• અને, અલબત્ત, અમારી પાસે ત્યાં કામ કરતા ઘણા સાથીદારો છે, ઘણી ટીમો છે. અને તે જાતે જ કરવું પડશે. અને આ અસુવિધાજનક છે.

અને તે કહેવું યોગ્ય છે કે અમારી પાસે ફક્ત એક જ પ્રયાસ છે, એક શોટ, જો આપણે ડેટાબેઝમાં કેટલાક ફેરફારો કરવા માંગતા હોવ, ડેટાને સ્પર્શ કરો, માળખું બદલો. અને જો કંઈક ખોટું થયું હોય, જો સ્થળાંતરમાં કોઈ ભૂલ હોય, તો અમે ઝડપથી પાછા ફરીશું નહીં.

આ અગાઉના અભિગમ કરતાં વધુ સારું છે, પરંતુ હજી પણ ઉચ્ચ સંભાવના છે કે અમુક પ્રકારની ભૂલ ઉત્પાદનમાં જશે.

દરેક ડેવલપરને ટેસ્ટ બેન્ચ, ફુલ સાઈઝ કોપી આપતા અમને શું રોકે છે? મને લાગે છે કે આમાં શું આવે છે તે સ્પષ્ટ છે.

કોની પાસે ટેરાબાઈટ કરતા મોટો ડેટાબેઝ છે? અડધાથી વધુ રૂમ.

અને તે સ્પષ્ટ છે કે દરેક વિકાસકર્તા માટે મશીનો રાખવા, જ્યારે આટલું મોટું ઉત્પાદન હોય, ત્યારે તે ખૂબ ખર્ચાળ છે, અને તે ઉપરાંત, તે ઘણો સમય લે છે.

અમારી પાસે એવા ક્લાયન્ટ્સ છે જેમને સમજાયું છે કે પૂર્ણ-કદની નકલો પર તમામ ફેરફારોનું પરીક્ષણ કરવું ખૂબ જ મહત્વપૂર્ણ છે, પરંતુ તેમનો ડેટાબેઝ એક ટેરાબાઈટ કરતા ઓછો છે, અને દરેક ડેવલપર માટે ટેસ્ટ બેન્ચ રાખવા માટે કોઈ સંસાધનો નથી. તેથી, તેઓએ તેમના મશીનમાં સ્થાનિક રીતે ડમ્પ ડાઉનલોડ કરવા પડશે અને આ રીતે પરીક્ષણ કરવું પડશે. તે ઘણો સમય લે છે.

જો તમે તેને ઇન્ફ્રાસ્ટ્રક્ચરની અંદર કરો છો, તો પણ કલાક દીઠ એક ટેરાબાઇટ ડેટા ડાઉનલોડ કરવાનું પહેલેથી જ ખૂબ સારું છે. પરંતુ તેઓ લોજિકલ ડમ્પ્સનો ઉપયોગ કરે છે, તેઓ ક્લાઉડમાંથી સ્થાનિક રીતે ડાઉનલોડ કરે છે. તેમના માટે, ઝડપ લગભગ 200 ગીગાબાઇટ્સ પ્રતિ કલાક છે. અને લોજિકલ ડમ્પમાંથી ફરી વળવા, ઇન્ડેક્સને રોલ અપ કરવા વગેરેમાં હજુ પણ સમય લાગે છે.

પરંતુ તેઓ આ અભિગમનો ઉપયોગ કરે છે કારણ કે તે તેમને ઉત્પાદનને વિશ્વસનીય રાખવા માટે પરવાનગી આપે છે.

આપણે અહીં શું કરી શકીએ? ચાલો ટેસ્ટ બેન્ચ સસ્તી બનાવીએ અને દરેક ડેવલપરને તેમની પોતાની ટેસ્ટ બેન્ચ આપીએ.

અને આ શક્ય છે.

અને આ અભિગમમાં, જ્યારે આપણે દરેક ડેવલપર માટે પાતળા ક્લોન્સ બનાવીએ છીએ, ત્યારે અમે તેને એક મશીન પર શેર કરી શકીએ છીએ. ઉદાહરણ તરીકે, જો તમારી પાસે 10TB ડેટાબેઝ છે અને તમે તેને 10 ડેવલપર્સને આપવા માંગો છો, તો તમારી પાસે XNUMX x XNUMXTB ડેટાબેઝ હોવાની જરૂર નથી. એક મશીનનો ઉપયોગ કરીને દરેક ડેવલપર માટે પાતળી અલગ નકલો બનાવવા માટે તમારે માત્ર એક મશીનની જરૂર છે. હું તમને થોડી વાર પછી કહીશ કે તે કેવી રીતે કાર્ય કરે છે.

વાસ્તવિક ઉદાહરણ:

• ડીબી - 4,5 ટેરાબાઇટ્સ.

• અમે 30 સેકન્ડમાં સ્વતંત્ર નકલો મેળવી શકીએ છીએ.

તમારે ટેસ્ટ સ્ટેન્ડ માટે રાહ જોવાની જરૂર નથી અને તે કેટલું મોટું છે તેના પર નિર્ભર છે. તમે તેને સેકન્ડોમાં મેળવી શકો છો. તે સંપૂર્ણપણે અલગ વાતાવરણ હશે, પરંતુ જે એકબીજાની વચ્ચે ડેટા શેર કરશે.

આ મહાન છે. અહીં આપણે જાદુ અને સમાંતર બ્રહ્માંડ વિશે વાત કરી રહ્યા છીએ.

અમારા કિસ્સામાં, આ OpenZFS સિસ્ટમનો ઉપયોગ કરીને કાર્ય કરે છે.

OpenZFS એ કૉપિ-ઑન-રાઇટ ફાઇલ સિસ્ટમ છે જે બૉક્સની બહાર સ્નેપશોટ અને ક્લોન્સને સપોર્ટ કરે છે. તે વિશ્વસનીય અને માપી શકાય તેવું છે. તેણીનું સંચાલન કરવું ખૂબ જ સરળ છે. તે શાબ્દિક રીતે બે ટીમોમાં તૈનાત કરી શકાય છે.

અન્ય વિકલ્પો છે:

• એલવીએમ,

• સંગ્રહ (ઉદાહરણ તરીકે, શુદ્ધ સંગ્રહ).

હું જે ડેટાબેઝ લેબ વિશે વાત કરી રહ્યો છું તે મોડ્યુલર છે. આ વિકલ્પોનો ઉપયોગ કરીને અમલ કરી શકાય છે. પરંતુ હમણાં માટે, અમે OpenZFS પર ધ્યાન કેન્દ્રિત કર્યું છે, કારણ કે LVM સાથે ખાસ કરીને સમસ્યાઓ હતી.

તે કેવી રીતે કામ કરે છે? જ્યારે પણ અમે ડેટાને બદલીએ છીએ ત્યારે તેને ફરીથી લખવાને બદલે, અમે તેને ફક્ત ચિહ્નિત કરીને સાચવીએ છીએ કે આ નવો ડેટા સમયના નવા બિંદુથી છે, એક નવો સ્નેપશોટ.

અને ભવિષ્યમાં, જ્યારે આપણે રોલબેક કરવા માંગીએ છીએ અથવા આપણે કોઈ જૂના સંસ્કરણમાંથી નવો ક્લોન બનાવવા માંગીએ છીએ, ત્યારે અમે ફક્ત કહીએ છીએ: "ઠીક છે, અમને આ રીતે ચિહ્નિત થયેલ ડેટાના બ્લોક્સ આપો."

અને આ વપરાશકર્તા આવા ડેટા સેટ સાથે કામ કરશે. તે ધીમે ધીમે તેમને બદલશે, તેના પોતાના સ્નેપશોટ બનાવશે.

અને અમે શાખા કરીશું. અમારા કેસમાં દરેક ડેવલપર પાસે પોતાનો ક્લોન રાખવાની તક હશે જેને તે સંપાદિત કરે છે અને જે ડેટા શેર કરવામાં આવે છે તે દરેકની વચ્ચે શેર કરવામાં આવશે.

ઘરે આવી સિસ્ટમ જમાવવા માટે, તમારે બે સમસ્યાઓ હલ કરવાની જરૂર છે:

• પ્રથમ ડેટાનો સ્ત્રોત છે, જ્યાંથી તમે તેને લેશો. તમે ઉત્પાદન સાથે પ્રતિકૃતિ સેટ કરી શકો છો. તમે પહેલાથી જ તમે ગોઠવેલા બેકઅપ્સનો ઉપયોગ કરી શકો છો, મને આશા છે. WAL-E, WAL-G અથવા બર્મન. અને જો તમે RDS અથવા Cloud SQL જેવા ક્લાઉડ સોલ્યુશનનો ઉપયોગ કરી રહ્યાં હોવ તો પણ તમે લોજિકલ ડમ્પનો ઉપયોગ કરી શકો છો. પરંતુ અમે હજી પણ તમને બેકઅપ્સનો ઉપયોગ કરવાની સલાહ આપીએ છીએ, કારણ કે આ અભિગમ સાથે તમે ફાઇલોની ભૌતિક રચનાને પણ જાળવી રાખશો, જે તમને તે મેટ્રિક્સની નજીક રહેવાની મંજૂરી આપશે જે તમે ઉત્પાદનમાં જોશો કે જે તે સમસ્યાઓને પકડવા માટે.

• બીજું તે છે જ્યાં તમે ડેટાબેઝ લેબને હોસ્ટ કરવા માંગો છો. તે ક્લાઉડ હોઈ શકે છે, તે ઓન-પ્રિમાઈસ હોઈ શકે છે. અહીં કહેવું જરૂરી છે કે ZFS ડેટા કમ્પ્રેશનને સપોર્ટ કરે છે. અને તે ખૂબ સારી રીતે કરે છે.

કલ્પના કરો કે આવા દરેક ક્લોન માટે, અમે આધાર સાથે જે કામગીરી કરીએ છીએ તેના આધારે, અમુક પ્રકારનો દેવ વધશે. આ માટે દેવને પણ જગ્યાની જરૂર પડશે. પરંતુ એ હકીકતને કારણે કે અમે 4,5 ટેરાબાઇટનો આધાર લીધો છે, ZFS તેને 3,5 ટેરાબાઇટ્સમાં સંકુચિત કરશે. આ સેટિંગ્સના આધારે બદલાઈ શકે છે. અને અમારી પાસે હજુ પણ દેવ માટે જગ્યા છે.

આવી સિસ્ટમનો ઉપયોગ વિવિધ કેસો માટે થઈ શકે છે.

• આ વિકાસકર્તાઓ છે, ક્વેરી માન્યતા માટે, ઓપ્ટિમાઇઝેશન માટે DBA.

• અમે તેને પ્રોડમાં રોલ આઉટ કરીએ તે પહેલાં ચોક્કસ સ્થાનાંતરણને ચકાસવા માટે QA પરીક્ષણમાં તેનો ઉપયોગ કરી શકાય છે. અને અમે વાસ્તવિક ડેટા સાથે QA માટે વિશેષ વાતાવરણ પણ વધારી શકીએ છીએ, જ્યાં તેઓ નવી કાર્યક્ષમતા ચકાસી શકે છે. અને તે રાહ જોવાના કલાકોને બદલે સેકંડ લેશે, અને કદાચ કેટલાક અન્ય કિસ્સાઓમાં જ્યાં પાતળી નકલોનો ઉપયોગ થતો નથી.

• અને બીજો કેસ. જો કંપની પાસે એનાલિટિક્સ સિસ્ટમ સેટઅપ નથી, તો પછી અમે પ્રોડક્ટ બેઝનો એક પાતળો ક્લોન અલગ કરી શકીએ છીએ અને તેને લાંબી ક્વેરી અથવા વિશિષ્ટ ઇન્ડેક્સને આપી શકીએ છીએ જેનો ઉપયોગ વિશ્લેષણમાં થઈ શકે છે.

આ અભિગમ સાથે:

1. "ઉત્પાદન" પર ભૂલોની ઓછી સંભાવના, કારણ કે અમે પૂર્ણ-કદના ડેટા પરના તમામ ફેરફારોનું પરીક્ષણ કર્યું છે.

2. અમારી પાસે પરીક્ષણની સંસ્કૃતિ છે, કારણ કે હવે તમારે તમારા પોતાના સ્ટેન્ડ માટે કલાકો સુધી રાહ જોવાની જરૂર નથી.

3. અને ત્યાં કોઈ અવરોધ નથી, પરીક્ષણો વચ્ચે કોઈ રાહ નથી. તમે ખરેખર જઈને તપાસ કરી શકો છો. અને આ રીતે તે વધુ સારું રહેશે કારણ કે આપણે વિકાસને ઝડપી બનાવીશું.

• ત્યાં ઓછું રિફેક્ટરિંગ હશે. ઉત્પાદનમાં ઓછા બગ્સ સમાપ્ત થશે. અમે તેમને પછીથી ઓછા રિફેક્ટ કરીશું.

• આપણે બદલી ન શકાય તેવા ફેરફારોને ઉલટાવી શકીએ છીએ. આ પ્રમાણભૂત અભિગમ નથી.

1. આ ફાયદાકારક છે કારણ કે અમે ટેસ્ટ બેન્ચના સંસાધનો શેર કરીએ છીએ.

પહેલેથી જ સારું છે, પરંતુ બીજું શું ત્વરિત કરી શકાય છે?

આવી સિસ્ટમ માટે આભાર, અમે આવા પરીક્ષણ દાખલ કરવા માટે થ્રેશોલ્ડને મોટા પ્રમાણમાં ઘટાડી શકીએ છીએ.

હવે એક દુષ્ટ વર્તુળ છે, જ્યારે વિકાસકર્તા, વાસ્તવિક પૂર્ણ-કદના ડેટાની ઍક્સેસ મેળવવા માટે, નિષ્ણાત બનવું આવશ્યક છે. આવી પહોંચ સાથે તેના પર વિશ્વાસ કરવો જ જોઇએ.

પરંતુ જો તે ત્યાં ન હોય તો કેવી રીતે વધવું. પરંતુ જો તમારી પાસે ટેસ્ટ ડેટાનો ખૂબ જ નાનો સેટ ઉપલબ્ધ હોય તો શું? પછી તમને કોઈ વાસ્તવિક અનુભવ નહીં મળે.

આ વર્તુળમાંથી કેવી રીતે બહાર નીકળવું? પ્રથમ ઇન્ટરફેસ તરીકે, કોઈપણ સ્તરના વિકાસકર્તાઓ માટે અનુકૂળ, અમે Slack bot પસંદ કર્યું છે. પરંતુ તે કોઈપણ અન્ય ઈન્ટરફેસ હોઈ શકે છે.

તે તમને શું કરવા દે છે? તમે ચોક્કસ ક્વેરી લઈ શકો છો અને તેને ડેટાબેઝ માટે વિશેષ ચેનલ પર મોકલી શકો છો. અમે સેકન્ડોમાં આપમેળે પાતળા ક્લોનને જમાવીશું. ચાલો આ વિનંતી ચલાવીએ. અમે મેટ્રિક્સ અને ભલામણો એકત્રિત કરીએ છીએ. ચાલો એક વિઝ્યુલાઇઝેશન બતાવીએ. અને પછી આ ક્લોન રહેશે જેથી આ ક્વેરી કોઈક રીતે ઑપ્ટિમાઇઝ કરી શકાય, ઇન્ડેક્સ ઉમેરી શકાય વગેરે.

અને Slack અમને બોક્સની બહાર સહયોગ માટેની તકો પણ આપે છે. આ માત્ર એક ચેનલ હોવાથી, તમે આવી વિનંતી માટે થ્રેડમાં જ આ વિનંતી વિશે ચર્ચા કરવાનું શરૂ કરી શકો છો, તમારા સહકાર્યકરોને, DBA ને પિંગ કરી શકો છો જે કંપનીની અંદર છે.

પરંતુ ત્યાં, અલબત્ત, સમસ્યાઓ છે. કારણ કે આ વાસ્તવિક દુનિયા છે, અને અમે એક સાથે ઘણા ક્લોન્સ હોસ્ટ કરતું સર્વર ચલાવી રહ્યા છીએ, અમારે ક્લોન્સ માટે ઉપલબ્ધ મેમરી અને CPU પાવરની માત્રાને સંકુચિત કરવી પડશે.

પરંતુ આ પરીક્ષણો બુદ્ધિગમ્ય બનવા માટે, તમારે આ સમસ્યાને કોઈક રીતે હલ કરવાની જરૂર છે.

તે સ્પષ્ટ છે કે મહત્વનો મુદ્દો એ જ ડેટા છે. પરંતુ અમારી પાસે પહેલેથી જ છે. અને અમે સમાન રૂપરેખાંકન પ્રાપ્ત કરવા માંગીએ છીએ. અને અમે લગભગ સમાન રૂપરેખાંકન આપી શકીએ છીએ.

ઉત્પાદનમાં સમાન હાર્ડવેર રાખવા માટે તે સરસ રહેશે, પરંતુ તે અલગ હોઈ શકે છે.

ચાલો યાદ રાખો કે પોસ્ટગ્રેસ મેમરી સાથે કેવી રીતે કાર્ય કરે છે. અમારી પાસે બે કેશ છે. એક ફાઇલ સિસ્ટમમાંથી અને એક મૂળ પોસ્ટગ્રેસ, એટલે કે વહેંચાયેલ બફર કેશ.

એ નોંધવું અગત્યનું છે કે જ્યારે પોસ્ટગ્રેસ શરૂ થાય ત્યારે વહેંચાયેલ બફર કેશ ફાળવવામાં આવે છે, તમે રૂપરેખાંકનમાં કયા માપનો ઉલ્લેખ કરો છો તેના આધારે.

અને બીજી કેશ બધી ઉપલબ્ધ જગ્યા વાપરે છે.

અને જ્યારે આપણે એક મશીન પર ઘણા ક્લોન્સ બનાવીએ છીએ, ત્યારે તે તારણ આપે છે કે આપણે ધીમે ધીમે મેમરી ભરીએ છીએ. અને સારી રીતે, શેર્ડ બફર કેશ એ મશીન પર ઉપલબ્ધ મેમરીની કુલ રકમના 25% છે.

અને તે તારણ આપે છે કે જો આપણે આ પરિમાણને બદલીશું નહીં, તો આપણે એક મશીન પર ફક્ત 4 દાખલાઓ ચલાવવા માટે સક્ષમ થઈશું, એટલે કે આવા તમામ પાતળા ક્લોન્સમાંથી 4. અને આ, અલબત્ત, ખરાબ છે, કારણ કે આપણે તેમાંથી ઘણું બધું મેળવવા માંગીએ છીએ.

પરંતુ બીજી તરફ, બફર કેશનો ઉપયોગ ઇન્ડેક્સ માટે ક્વેરી ચલાવવા માટે થાય છે, એટલે કે, અમારી કેશ કેટલી મોટી છે તેના પર પ્લાન આધાર રાખે છે. અને જો આપણે ફક્ત આ પરિમાણ લઈએ અને તેને ઘટાડીએ, તો આપણી યોજનાઓ ઘણી બદલાઈ શકે છે.

ઉદાહરણ તરીકે, જો અમારી પાસે પ્રોડ પર મોટી કેશ છે, તો પોસ્ટગ્રેસ ઇન્ડેક્સનો ઉપયોગ કરવાનું પસંદ કરશે. અને જો નહીં, તો ત્યાં SeqScan હશે. અને જો અમારી યોજનાઓ એકરૂપ ન થાય તો શું ફાયદો થશે?

પરંતુ અહીં અમે નિષ્કર્ષ પર આવીએ છીએ કે વાસ્તવમાં પોસ્ટગ્રેસમાં યોજના યોજનામાં શેર કરેલ બફરમાં ઉલ્લેખિત ચોક્કસ કદ પર આધારિત નથી, તે અસરકારક_કેશ_સાઇઝ પર આધારિત છે.

Effective_cache_size એ કેશનો અંદાજિત જથ્થો છે જે અમને ઉપલબ્ધ છે, એટલે કે બફર કેશ અને ફાઇલ સિસ્ટમ કેશનો સરવાળો. આ રૂપરેખા દ્વારા સુયોજિત થયેલ છે. અને આ મેમરી ફાળવવામાં આવી નથી.

અને આ પરિમાણને લીધે, અમે પોસ્ટગ્રેસને એવી યુક્તિ કરી શકીએ છીએ કે અમારી પાસે ખરેખર ઘણો ડેટા ઉપલબ્ધ છે, ભલે અમારી પાસે આ ડેટા ન હોય. અને આમ, યોજનાઓ સંપૂર્ણપણે ઉત્પાદન સાથે સુસંગત રહેશે.

પરંતુ આ સમયને અસર કરી શકે છે. અને અમે સમય દ્વારા પ્રશ્નોને ઑપ્ટિમાઇઝ કરીએ છીએ, પરંતુ તે મહત્વપૂર્ણ છે કે સમય ઘણા પરિબળો પર આધારિત છે:

• તે લોડ પર આધાર રાખે છે જે હાલમાં ઉત્પાદન પર છે.

• તે મશીનની લાક્ષણિકતાઓ પર આધારિત છે.

અને આ એક પરોક્ષ પરિમાણ છે, પરંતુ વાસ્તવમાં પરિણામ મેળવવા માટે આ ક્વેરી વાંચશે તે ડેટાની માત્રા દ્વારા આપણે બરાબર ઑપ્ટિમાઇઝ કરી શકીએ છીએ.

અને જો તમે ઇચ્છતા હોવ કે આપણે ઉત્પાદનમાં જે જોઈશું તેની નજીકનો સમય હોય, તો અમારે સૌથી સમાન હાર્ડવેર લેવાની જરૂર છે અને સંભવતઃ, તેનાથી પણ વધુ જેથી તમામ ક્લોન્સ ફિટ થઈ જાય. પરંતુ આ એક સમાધાન છે, એટલે કે તમને સમાન યોજનાઓ મળશે, તમે જોશો કે ચોક્કસ ક્વેરી કેટલો ડેટા વાંચશે અને તમે નિષ્કર્ષ પર આવી શકશો કે આ ક્વેરી સારી (અથવા સ્થળાંતર) છે કે ખરાબ, તેને હજુ પણ ઑપ્ટિમાઇઝ કરવાની જરૂર છે. .

ચાલો એક નજર કરીએ કે જૉ ખાસ કેવી રીતે ઑપ્ટિમાઇઝ થાય છે.

ચાલો વાસ્તવિક સિસ્ટમની વિનંતી લઈએ. આ કિસ્સામાં, ડેટાબેઝ 1 ટેરાબાઇટ છે. અને અમે 10 થી વધુ લાઈક્સ ધરાવતી નવી પોસ્ટની સંખ્યા ગણવા માંગીએ છીએ.

અમે ચેનલને સંદેશ લખી રહ્યા છીએ, અમારા માટે ક્લોન તૈનાત કરવામાં આવ્યો છે. અને અમે જોશું કે આવી વિનંતી 2,5 મિનિટમાં પૂર્ણ થશે. આ પહેલી વસ્તુ છે જે આપણે નોંધીએ છીએ.

B Joe તમને પ્લાન અને મેટ્રિક્સના આધારે સ્વચાલિત ભલામણો બતાવશે.

આપણે જોઈશું કે ક્વેરી પ્રમાણમાં ઓછી સંખ્યામાં પંક્તિઓ મેળવવા માટે ખૂબ વધારે ડેટાની પ્રક્રિયા કરે છે. અને અમુક પ્રકારના વિશિષ્ટ ઇન્ડેક્સની જરૂર છે, કારણ કે અમે નોંધ્યું છે કે ક્વેરી માં ઘણી બધી ફિલ્ટર કરેલ પંક્તિઓ છે.

ચાલો શું થયું તેના પર નજીકથી નજર કરીએ. ખરેખર, આપણે જોઈએ છીએ કે આપણે ફાઈલ કેશમાંથી અથવા તો ડિસ્કમાંથી લગભગ દોઢ ગીગાબાઈટ ડેટા વાંચ્યો છે. અને આ સારું નથી, કારણ કે અમને ફક્ત 142 લાઇન મળી છે.

અને, એવું લાગે છે કે, અમારી પાસે અહીં ઇન્ડેક્સ સ્કેન છે અને ઝડપથી કામ કરવું જોઈતું હતું, પરંતુ અમે ઘણી બધી લાઈનોને ફિલ્ટર કરી દીધી હોવાથી (અમારે તેમને ગણવા પડ્યા હતા), ક્વેરી ધીમે ધીમે બહાર આવી.

અને આ યોજનામાં એ હકીકતને કારણે થયું છે કે ક્વેરી અને ઇન્ડેક્સની શરતો આંશિક રીતે મેળ ખાતી નથી.

ચાલો અનુક્રમણિકાને વધુ ચોક્કસ બનાવવાનો પ્રયાસ કરીએ અને તે પછી ક્વેરી એક્ઝિક્યુશન કેવી રીતે બદલાય છે તે જોઈએ.

ઇન્ડેક્સની રચનામાં ઘણો લાંબો સમય લાગ્યો, પરંતુ હવે અમે ક્વેરી તપાસીએ છીએ અને જોઈએ છીએ કે 2,5 મિનિટને બદલે સમય ફક્ત 156 મિલિસેકન્ડનો છે, જે પૂરતો સારો છે. અને આપણે ફક્ત 6 મેગાબાઈટ ડેટા વાંચીએ છીએ.

અને હવે આપણે ફક્ત ઇન્ડેક્સ સ્કેનનો ઉપયોગ કરીએ છીએ.

બીજી મહત્વની વાર્તા એ છે કે અમે યોજનાને વધુ સમજી શકાય તેવી રીતે રજૂ કરવા માંગીએ છીએ. અમે ફ્લેમ ગ્રાફ્સનો ઉપયોગ કરીને વિઝ્યુલાઇઝેશનનો અમલ કર્યો છે.

આ એક અલગ વિનંતી છે, વધુ તીવ્ર. અને અમે બે પરિમાણો અનુસાર ફ્લેમ ગ્રાફ બનાવીએ છીએ: આ ડેટાનો જથ્થો છે જે ચોક્કસ નોડ દ્વારા પ્લાન અને ટાઇમિંગમાં ગણવામાં આવે છે, એટલે કે નોડનો અમલ કરવાનો સમય.

અહીં આપણે ચોક્કસ ગાંઠો એકબીજા સાથે સરખાવી શકીએ છીએ. અને તે સ્પષ્ટ થશે કે તેમાંથી કોણ વધુ કે ઓછું લે છે, જે સામાન્ય રીતે અન્ય રેન્ડરીંગ પદ્ધતિઓમાં કરવું મુશ્કેલ છે.

અલબત્ત, દરેક વ્યક્તિ explain.depesz.com જાણે છે. આ વિઝ્યુલાઇઝેશનની સારી વિશેષતા એ છે કે અમે ટેક્સ્ટ પ્લાનને સાચવીએ છીએ અને કેટલાક મૂળભૂત પરિમાણોને ટેબલમાં પણ મૂકીએ છીએ જેથી કરીને અમે સૉર્ટ કરી શકીએ.

અને વિકાસકર્તાઓ કે જેમણે હજી સુધી આ વિષયમાં અભ્યાસ કર્યો નથી તેઓ પણ explain.depesz.com નો ઉપયોગ કરે છે, કારણ કે તેમના માટે કયું મેટ્રિક્સ મહત્વપૂર્ણ છે અને કયા નથી તે શોધવાનું સરળ છે.

વિઝ્યુલાઇઝેશન માટે એક નવો અભિગમ છે - આ છે explain.dalibo.com. તેઓ વૃક્ષ વિઝ્યુલાઇઝેશન કરે છે, પરંતુ એકબીજા સાથે ગાંઠોની તુલના કરવી ખૂબ જ મુશ્કેલ છે. અહીં તમે સ્ટ્રક્ચરને સારી રીતે સમજી શકો છો, જો કે, જો કોઈ મોટી વિનંતી હોય, તો તમારે આગળ પાછળ સ્ક્રોલ કરવાની જરૂર પડશે, પણ એક વિકલ્પ પણ.

સહયોગ

અને, મેં કહ્યું તેમ, Slack અમને સહયોગ કરવાની તક આપે છે. ઉદાહરણ તરીકે, જો અમને કોઈ જટિલ ક્વેરી આવે કે જે ઑપ્ટિમાઇઝ કેવી રીતે કરવું તે સ્પષ્ટ નથી, તો અમે Slack માં થ્રેડમાં અમારા સાથીદારો સાથે આ મુદ્દાને સ્પષ્ટ કરી શકીએ છીએ.

અમને લાગે છે કે પૂર્ણ-કદના ડેટા પર પરીક્ષણ કરવું મહત્વપૂર્ણ છે. આ કરવા માટે, અમે અપડેટ ડેટાબેઝ લેબ ટૂલ બનાવ્યું છે, જે ઓપન સોર્સમાં ઉપલબ્ધ છે. તમે જૉ બૉટનો પણ ઉપયોગ કરી શકો છો. તમે તેને હમણાં જ લઈ શકો છો અને તેને તમારા સ્થાને અમલમાં મૂકી શકો છો. બધા માર્ગદર્શિકાઓ ત્યાં ઉપલબ્ધ છે.

એ નોંધવું પણ મહત્વનું છે કે સોલ્યુશન પોતે ક્રાંતિકારી નથી, કારણ કે ડેલ્ફિક્સ છે, પરંતુ તે એક એન્ટરપ્રાઇઝ સોલ્યુશન છે. તે સંપૂર્ણપણે બંધ છે, તે ખૂબ ખર્ચાળ છે. અમે ખાસ કરીને પોસ્ટગ્રેસમાં નિષ્ણાત છીએ. આ તમામ ઓપન સોર્સ પ્રોડક્ટ્સ છે. અમારી સાથ જોડાઓ!

આ તે છે જ્યાં હું સમાપ્ત. આભાર!

પ્રશ્નો

નમસ્તે! રિપોર્ટ માટે આભાર! ખૂબ જ રસપ્રદ, ખાસ કરીને મારા માટે, કારણ કે મેં થોડા સમય પહેલા આ જ સમસ્યાનું નિરાકરણ કર્યું હતું. અને તેથી મારી પાસે સંખ્યાબંધ પ્રશ્નો છે. આશા છે કે હું તેનો ઓછામાં ઓછો ભાગ મેળવીશ.

મને આશ્ચર્ય થાય છે કે તમે આ પર્યાવરણ માટે સ્થળની ગણતરી કેવી રીતે કરો છો? ટેક્નોલોજીનો અર્થ એ છે કે ચોક્કસ સંજોગોમાં, તમારા ક્લોન્સ મહત્તમ કદ સુધી વધી શકે છે. સામાન્ય રીતે કહીએ તો, જો તમારી પાસે દસ ટેરાબાઇટ ડેટાબેઝ અને 10 ક્લોન્સ હોય, તો એવી પરિસ્થિતિનું અનુકરણ કરવું સરળ છે જ્યાં દરેક ક્લોનનું વજન 10 અનન્ય ડેટા હોય. તમે આ સ્થાનની ગણતરી કેવી રીતે કરશો, એટલે કે તે ડેલ્ટા કે જેના વિશે તમે વાત કરી છે, જેમાં આ ક્લોન્સ રહેશે?

સારો પ્રશ્ન. અહીં ચોક્કસ ક્લોન્સનો ટ્રેક રાખવો મહત્વપૂર્ણ છે. અને જો કોઈ ક્લોનમાં થોડો ઘણો મોટો ફેરફાર હોય, તે વધવા લાગે, તો અમે પહેલા તેના વિશે યુઝરને ચેતવણી આપી શકીએ છીએ, અથવા તરત જ આ ક્લોનને બંધ કરી શકીએ છીએ જેથી અમારી નિષ્ફળ પરિસ્થિતિ ન આવે.

હા, મારી પાસે એક નેસ્ટેડ પ્રશ્ન છે. એટલે કે, તમે આ મોડ્યુલોના જીવન ચક્રની ખાતરી કેવી રીતે કરશો? અમારી પાસે આ સમસ્યા છે અને એક સંપૂર્ણ અલગ વાર્તા છે. આ કેવી રીતે થાય છે?

દરેક ક્લોન માટે અમુક ttl છે. મૂળભૂત રીતે, અમારી પાસે નિશ્ચિત ttl છે.

શું, જો ગુપ્ત નથી?

1 કલાક, એટલે કે નિષ્ક્રિય - 1 કલાક. જો તેનો ઉપયોગ ન થાય, તો અમે તેને બેંગ કરીએ છીએ. પરંતુ અહીં કોઈ આશ્ચર્ય નથી, કારણ કે આપણે ક્લોનને સેકન્ડોમાં વધારી શકીએ છીએ. અને જો તમને ફરીથી તેની જરૂર હોય, તો કૃપા કરીને.

મને તકનીકોની પસંદગીમાં પણ રસ છે, કારણ કે, ઉદાહરણ તરીકે, અમે એક અથવા બીજા કારણોસર સમાંતરમાં ઘણી પદ્ધતિઓનો ઉપયોગ કરીએ છીએ. શા માટે ZFS? તમે LVM નો ઉપયોગ કેમ ન કર્યો? તમે ઉલ્લેખ કર્યો છે કે LVM સાથે સમસ્યાઓ હતી. શું સમસ્યાઓ હતી? મારા મતે, પ્રદર્શનની દ્રષ્ટિએ, સંગ્રહ સાથેનો સૌથી શ્રેષ્ઠ વિકલ્પ છે.

ZFS સાથે મુખ્ય સમસ્યા શું છે? હકીકત એ છે કે તમારે એક જ હોસ્ટ પર ચાલવું આવશ્યક છે, એટલે કે તમામ ઉદાહરણો સમાન OS માં જીવશે. અને સ્ટોરેજના કિસ્સામાં, તમે વિવિધ સાધનોને કનેક્ટ કરી શકો છો. અને અડચણ ફક્ત તે જ બ્લોક્સ છે જે સ્ટોરેજ સિસ્ટમ પર છે. અને તકનીકોની પસંદગીનો પ્રશ્ન રસપ્રદ છે. એલવીએમ કેમ નહીં?

ખાસ કરીને, અમે બેઠકમાં LVM વિશે ચર્ચા કરી શકીએ છીએ. સંગ્રહ વિશે - તે માત્ર ખર્ચાળ છે. અમે ગમે ત્યાં ZFS સિસ્ટમનો અમલ કરી શકીએ છીએ. તમે તેને તમારા મશીન પર જમાવી શકો છો. તમે ખાલી રીપોઝીટરી ડાઉનલોડ કરી શકો છો અને તેને જમાવી શકો છો. જો આપણે Linux વિશે વાત કરીએ તો ZFS લગભગ દરેક જગ્યાએ ઇન્સ્ટોલ કરેલું છે. એટલે કે, અમને ખૂબ જ લવચીક ઉકેલ મળે છે. અને બોક્સની બહાર, ZFS ઘણું બધું આપે છે. તમે ગમે તેટલો ડેટા અપલોડ કરી શકો છો, મોટી સંખ્યામાં ડિસ્કને કનેક્ટ કરી શકો છો, ત્યાં સ્નેપશોટ છે. અને, મેં કહ્યું તેમ, તેનું સંચાલન કરવું સરળ છે. એટલે કે, તે વાપરવા માટે ખૂબ જ સુખદ લાગે છે. તેની કસોટી થઈ છે, તે ઘણા વર્ષોનો છે. તેમની પાસે ખૂબ જ વિશાળ સમુદાય છે જે વધી રહ્યો છે. ZFS એ ખૂબ જ વિશ્વસનીય ઉકેલ છે.

નિકોલાઈ સમોખવાલોવ: શું હું વધુ ટિપ્પણી કરી શકું? મારું નામ નિકોલે છે, અમે એનાટોલી સાથે મળીને કામ કરીએ છીએ. હું સંમત છું કે સંગ્રહ મહાન છે. અને અમારા કેટલાક ગ્રાહકો પાસે પ્યોર સ્ટોરેજ વગેરે છે.

એનાટોલીએ યોગ્ય રીતે નોંધ્યું છે કે અમે મોડ્યુલારિટી પર ધ્યાન કેન્દ્રિત કર્યું છે. અને ભવિષ્યમાં, તમે એક ઇન્ટરફેસનો અમલ કરી શકો છો - સ્નેપશોટ લો, ક્લોન બનાવો, ક્લોનનો નાશ કરો. તે બધું સરળ છે. અને સંગ્રહ ઠંડી છે, જો તે છે.

પરંતુ ZFS દરેક માટે ઉપલબ્ધ છે. ડેલફિક્સ પહેલેથી જ પૂરતું છે, તેમની પાસે 300 ક્લાયંટ છે. આમાંથી, fortune 100 પાસે 50 ક્લાયન્ટ્સ છે, એટલે કે તેઓ નાસા વગેરેને લક્ષ્યમાં રાખે છે. દરેકને આ ટેક્નોલોજી મેળવવાનો સમય આવી ગયો છે. અને તેથી જ અમારી પાસે ઓપન સોર્સ કોર છે. અમારી પાસે એક ઇન્ટરફેસ ભાગ છે જે ઓપન સોર્સ નથી. આ તે પ્લેટફોર્મ છે જે અમે બતાવીશું. પરંતુ અમે ઇચ્છીએ છીએ કે તે દરેક માટે સુલભ હોય. અમે એક ક્રાંતિ કરવા માંગીએ છીએ જેથી બધા પરીક્ષકો લેપટોપ પર અનુમાન લગાવવાનું બંધ કરે. આપણે SELECT લખવાનું છે અને તરત જ જોવું પડશે કે તે ધીમું છે. DBA તમને તેના વિશે જણાવે તેની રાહ જોવાનું બંધ કરો. અહીં મુખ્ય ધ્યેય છે. અને મને લાગે છે કે આપણે બધા આ તરફ આવીશું. અને અમે આ વસ્તુ દરેક માટે બનાવીએ છીએ. તેથી ZFS, કારણ કે તે દરેક જગ્યાએ ઉપલબ્ધ હશે. સમસ્યાઓ ઉકેલવા અને ઓપન સોર્સ લાયસન્સ વગેરે રાખવા બદલ સમુદાયનો આભાર*

શુભેચ્છાઓ! રિપોર્ટ માટે આભાર! મારું નામ મેક્સિમ છે. અમે સમાન મુદ્દાઓ સાથે વ્યવહાર કર્યો છે. તેઓએ પોતાના પર નિર્ણય કર્યો. તમે આ ક્લોન્સ વચ્ચે સંસાધનો કેવી રીતે શેર કરશો? દરેક ક્લોન કોઈપણ સમયે તેની પોતાની વસ્તુ કરી શકે છે: કોઈ એક વસ્તુનું પરીક્ષણ કરે છે, બીજું બીજું, કોઈ ઇન્ડેક્સ બનાવે છે, કોઈ પાસે ભારે કામ છે. અને જો તમે હજુ પણ CPU દ્વારા ભાગાકાર કરી શકો છો, તો IO દ્વારા, તમે કેવી રીતે ભાગાકાર કરશો? આ પહેલો પ્રશ્ન છે.

અને બીજો પ્રશ્ન સ્ટેન્ડની અસમાનતા વિશે છે. ચાલો કહીએ કે મારી પાસે અહીં ZFS છે અને બધું સરસ છે, પરંતુ પ્રોડ પરના ક્લાયંટ પાસે ZFS નથી, પરંતુ ext4, ઉદાહરણ તરીકે. આ કિસ્સામાં કેવી રીતે?

પ્રશ્નો ખૂબ સારા છે. મેં આ સમસ્યાનો ઉલ્લેખ એ હકીકત સાથે કર્યો છે કે અમે સંસાધનો વહેંચીએ છીએ. અને ઉકેલ આ છે. કલ્પના કરો કે તમે સ્ટેજિંગ પર પરીક્ષણ કરી રહ્યાં છો. તમારી પાસે પણ એવી પરિસ્થિતિ આવી શકે છે કે કોઈ એક ભાર આપે, કોઈ બીજું. અને પરિણામે, તમે મેટ્રિક્સ જુઓ છો જે અગમ્ય છે. પ્રોડમાં પણ સમાન સમસ્યા હોઈ શકે છે. જ્યારે તમે અમુક વિનંતીને તપાસવા માંગો છો અને તમે જુઓ છો કે તેની સાથે થોડી સમસ્યા છે - તે ધીમે ધીમે કાર્ય કરે છે, તો હકીકતમાં સમસ્યા વિનંતીમાં ન હતી, પરંતુ હકીકત એ છે કે અમુક પ્રકારનો સમાંતર લોડ છે.

અને તેથી, આ યોજના શું હશે, અમે યોજનામાં કયા પગલાં લઈશું અને આ માટે કેટલો ડેટા એકત્રિત કરીશું તેના પર ધ્યાન કેન્દ્રિત કરવું અહીં મહત્વપૂર્ણ છે. હકીકત એ છે કે અમારી ડિસ્ક, ઉદાહરણ તરીકે, કંઈક સાથે લોડ કરવામાં આવશે, તે ખાસ કરીને સમયને અસર કરશે. પરંતુ અમે ડેટાના જથ્થા દ્વારા આ વિનંતી કેટલી લોડ કરવામાં આવી છે તેનો અંદાજ લગાવી શકીએ છીએ. તે એટલું મહત્વનું નથી કે તે જ સમયે કોઈ પ્રકારનો અમલ થશે.

મારા બે પ્રશ્નો છે. આ ખૂબ જ સરસ વસ્તુ છે. શું એવા કિસ્સાઓ છે કે જ્યાં ઉત્પાદન ડેટા મહત્વપૂર્ણ છે, જેમ કે ક્રેડિટ કાર્ડ નંબર? શું ત્યાં પહેલેથી જ કંઈક તૈયાર છે અથવા તે એક અલગ કાર્ય છે? અને બીજો પ્રશ્ન - શું MySQL માટે આવું કંઈક છે?

ડેટા વિશે. જ્યાં સુધી અમે નહીં કરીએ ત્યાં સુધી અમે અસ્પષ્ટતા કરીશું. પરંતુ જો તમે બરાબર જૉ જમાવશો, જો તમે વિકાસકર્તાઓને ઍક્સેસ ન આપો, તો ડેટાની કોઈ ઍક્સેસ નથી. શા માટે? કારણ કે જૉ ડેટા બતાવતો નથી. તે માત્ર મેટ્રિક્સ, યોજનાઓ બતાવે છે અને બસ. આ હેતુસર કરવામાં આવ્યું હતું, કારણ કે આ અમારા ક્લાયંટની આવશ્યકતાઓમાંની એક છે. તેઓ દરેકને ઍક્સેસ આપ્યા વિના ઑપ્ટિમાઇઝ કરવા સક્ષમ બનવા માગતા હતા.

MySQL વિશે. આ સિસ્ટમનો ઉપયોગ કોઈપણ વસ્તુ માટે થઈ શકે છે જે ડિસ્ક પર સ્ટેટ સ્ટોર કરે છે. અને અમે પોસ્ટગ્રેસ કરી રહ્યા હોવાથી, અમે હવે પોસ્ટગ્રેસ માટે તમામ ઓટોમેશન પ્રથમ અને અગ્રણી કરી રહ્યા છીએ. અમે બેકઅપમાંથી ડેટા મેળવવાને સ્વચાલિત કરવા માંગીએ છીએ. અમે Postgres ને યોગ્ય રીતે ગોઠવી રહ્યા છીએ. અમે જાણીએ છીએ કે યોજનાઓ કેવી રીતે મેચ કરવી વગેરે.

પરંતુ સિસ્ટમ એક્સ્ટેન્સિબલ હોવાથી, તેનો ઉપયોગ MySQL માટે પણ થઈ શકે છે. અને આવા ઉદાહરણો છે. યાન્ડેક્ષ પાસે સમાન વસ્તુ છે, પરંતુ તેઓ તેને ક્યાંય પ્રકાશિત કરતા નથી. તેઓ તેનો ઉપયોગ Yandex.Metrica ની અંદર કરે છે. અને MySQL વિશે માત્ર એક વાર્તા છે. પરંતુ તકનીકો સમાન છે, ZFS.

રિપોર્ટ માટે આભાર! મારે પણ કેટલાક પ્રશ્નો છે. તમે ઉલ્લેખ કર્યો છે કે ક્લોનિંગનો ઉપયોગ એનાલિટિક્સ માટે થઈ શકે છે, ઉદાહરણ તરીકે ત્યાં વધારાના ઇન્ડેક્સ બનાવવા માટે. શું તમે તે કેવી રીતે કાર્ય કરે છે તે વિશે થોડું વધુ કહી શકો છો?

અને હું તરત જ સ્ટેન્ડની સમાનતા, યોજનાઓની સમાનતા વિશે બીજો પ્રશ્ન પૂછીશ. યોજના પોસ્ટગ્રેસ દ્વારા એકત્રિત કરવામાં આવેલા આંકડા પર પણ આધાર રાખે છે. તમે આ સમસ્યાને કેવી રીતે હલ કરશો?

એનાલિટિક્સ અનુસાર, ત્યાં કોઈ ચોક્કસ કેસ નથી, કારણ કે અમે હજી સુધી તેનો ઉપયોગ કર્યો નથી, પરંતુ આવી તક છે. જો આપણે અનુક્રમણિકાઓ વિશે વાત કરી રહ્યા છીએ, તો કલ્પના કરો કે ક્વેરી લાખો રેકોર્ડ્સ સાથેના ટેબલનો પીછો કરી રહી છે અને એક કૉલમ જે સામાન્ય રીતે ઉત્પાદનમાં અનુક્રમિત નથી. અને અમે ત્યાં કેટલાક ડેટાની ગણતરી કરવા માંગીએ છીએ. જો આ વિનંતી પ્રોડ પર મોકલવામાં આવે છે, તો એવી સંભાવના છે કે તે પ્રોડ પર સરળ હશે, કારણ કે વિનંતી ત્યાં એક મિનિટ માટે પ્રક્રિયા કરવામાં આવશે.

ઠીક છે, ચાલો એક પાતળા ક્લોન બનાવીએ જે થોડી મિનિટો માટે રોકવા માટે ભયંકર નથી. અને એનાલિટિક્સ વાંચવા માટે તેને વધુ આરામદાયક બનાવવા માટે, અમે તે કૉલમ માટે સૂચકાંકો ઉમેરીશું જેમાં અમને ડેટામાં રસ છે.

દરેક વખતે ઇન્ડેક્સ બનાવવામાં આવશે?

તમે તેને બનાવી શકો છો જેથી અમે ડેટાને સ્પર્શ કરીએ, સ્નેપશોટ બનાવીએ, પછી અમે આ સ્નેપશોટમાંથી પુનઃપ્રાપ્ત કરીશું અને નવી વિનંતીઓ ચલાવીશું. એટલે કે, તમે તેને બનાવી શકો છો જેથી કરીને તમે પહેલાથી જોડાયેલા સૂચકાંકો સાથે નવા ક્લોન્સ ઉભા કરી શકો.

આંકડા વિશેના પ્રશ્ન માટે, જો આપણે બેકઅપમાંથી પુનઃસ્થાપિત કરીએ, જો આપણે પ્રતિકૃતિ કરીએ, તો આપણા આંકડા બરાબર એ જ હશે. કારણ કે અમારી પાસે સંપૂર્ણ ભૌતિક ડેટા માળખું છે, એટલે કે, અમે તમામ આંકડા મેટ્રિક્સ સાથે પણ ડેટા લાવીશું.

અહીં બીજી સમસ્યા છે. જો તમે ક્લાઉડ સોલ્યુશનનો ઉપયોગ કરો છો, તો ત્યાં ફક્ત લોજિકલ ડમ્પ ઉપલબ્ધ છે, કારણ કે Google, Amazon તમને ભૌતિક નકલ લેવાની મંજૂરી આપતા નથી. આવી સમસ્યા હશે.

રિપોર્ટ માટે આભાર. MySQL અને રિસોર્સ શેરિંગ વિશે અહીં બે સારા પ્રશ્નો હતા. પરંતુ, વાસ્તવમાં, તે બધું એ હકીકત પર આવે છે કે આ ચોક્કસ DBMS નો વિષય નથી, પરંતુ સમગ્ર ફાઇલ સિસ્ટમનો છે. અને, તે મુજબ, સંસાધનોની વહેંચણીના મુદ્દાઓ પણ ત્યાંથી ઉકેલવા જોઈએ, અંતે તે પોસ્ટગ્રેસ નથી, પરંતુ ફાઇલ સિસ્ટમમાં, સર્વરમાં, ઉદાહરણ તરીકે.

મારો પ્રશ્ન થોડો જુદો છે. તે બહુ-સ્તરવાળા ડેટાબેઝની નજીક છે, જ્યાં ઘણા સ્તરો છે. ઉદાહરણ તરીકે, અમે દસ-ટેરાબાઇટ ઇમેજ અપડેટ સેટ કરીએ છીએ, અમે નકલ કરી રહ્યા છીએ. અને અમે ખાસ કરીને ડેટાબેઝ માટે આ સોલ્યુશનનો ઉપયોગ કરીએ છીએ. પ્રતિકૃતિ પ્રક્રિયામાં છે, ડેટા અપડેટ કરવામાં આવી રહ્યો છે. અહીં 100 કર્મચારીઓ સમાંતર કામ કરી રહ્યા છે, જેઓ સતત આ અલગ-અલગ શોટ્સ શરૂ કરી રહ્યા છે. શુ કરવુ? કેવી રીતે ખાતરી કરવી કે કોઈ સંઘર્ષ નથી, તેઓએ એક લોન્ચ કર્યું, અને પછી ફાઇલ સિસ્ટમ બદલાઈ, અને આ ચિત્રો બધા ગયા?

તેઓ જશે નહીં કારણ કે આ રીતે ZFS કામ કરે છે. પ્રતિકૃતિને કારણે આવતા ફાઈલ સિસ્ટમ ફેરફારોને આપણે એક થ્રેડમાં અલગથી રાખી શકીએ છીએ. અને ડેવલપર્સ ડેટાના જૂના વર્ઝન પર ઉપયોગ કરે છે તે ક્લોન્સ રાખો. અને તે આપણા માટે કામ કરે છે, બધું આ સાથે ક્રમમાં છે.

તે તારણ આપે છે કે અપડેટ વધારાના સ્તર તરીકે થશે, અને બધા નવા ચિત્રો આ સ્તરના આધારે પહેલેથી જ જશે, બરાબર?

અગાઉના સ્તરોમાંથી જે અગાઉના પ્રતિકૃતિઓમાંથી હતા.

અગાઉના સ્તરો પડી જશે, પરંતુ તેઓ જૂના સ્તરનો સંદર્ભ લેશે, અને શું તેઓ અપડેટમાં પ્રાપ્ત થયેલા છેલ્લા સ્તરમાંથી નવી છબીઓ લેશે?

સામાન્ય રીતે, હા.

પછી પરિણામે આપણી પાસે અંજીર સુધીના સ્તરો હશે. અને સમય જતાં તેઓને સંકુચિત કરવાની જરૂર પડશે?

હા બધું સાચું છે. થોડી બારી છે. અમે સાપ્તાહિક સ્નેપશોટ રાખીએ છીએ. તે તમારી પાસે કયા સંસાધન છે તેના પર નિર્ભર છે. જો તમારી પાસે ઘણો ડેટા સ્ટોર કરવાની ક્ષમતા હોય, તો તમે લાંબા સમય સુધી સ્નેપશોટ સ્ટોર કરી શકો છો. તેઓ તેમના પોતાના પર જશે નહીં. ડેટા કરપ્શન થશે નહીં. જો સ્નેપશોટ જૂના થઈ ગયા હોય, જેમ કે તે અમને લાગે છે, એટલે કે તે કંપનીની નીતિ પર આધારિત છે, તો અમે તેને ખાલી કરી શકીએ છીએ અને જગ્યા ખાલી કરી શકીએ છીએ.

હેલો, રિપોર્ટ માટે આભાર! જૉ વિશે પ્રશ્ન. તમે કહ્યું કે ગ્રાહક દરેકને ડેટાની ઍક્સેસ આપવા માંગતો નથી. કડક શબ્દોમાં કહીએ તો, જો કોઈ વ્યક્તિ પાસે એક્સપ્લેન એનાલિઝનું પરિણામ છે, તો તે ડેટાને પીપ કરી શકે છે.

એવું છે. ઉદાહરણ તરીકે, અમે લખી શકીએ છીએ: "સિલેક્ટ ફ્રોમ વ્હેર ઈમેલ = તે માટે". એટલે કે, આપણે ડેટા પોતે જોઈશું નહીં, પરંતુ આપણે કેટલાક પરોક્ષ સંકેતો જોઈ શકીએ છીએ. આ સમજવું જોઈએ. પરંતુ બીજી બાજુ, તે બધું ત્યાં છે. અમારી પાસે લોગ ઓડિટ છે, અમારી પાસે અન્ય સહકર્મીઓનું નિયંત્રણ છે જે વિકાસકર્તાઓ શું કરી રહ્યા છે તે પણ જુએ છે. અને જો કોઈ આ કરવાનો પ્રયાસ કરશે, તો સુરક્ષા સેવા તેમની પાસે આવશે અને આ મુદ્દા પર કામ કરશે.

શુભ બપોર રિપોર્ટ માટે આભાર! મારી પાસે એક નાનો પ્રશ્ન છે. જો કંપની સ્લૅકનો ઉપયોગ કરતી નથી, તો શું હવે તેના માટે કોઈ બંધનકર્તા છે, અથવા ડેવલપર્સ માટે ટેસ્ટ એપ્લિકેશનને ડેટાબેસેસ સાથે કનેક્ટ કરવા માટે દાખલાઓ જમાવવાનું શક્ય છે?

હવે સ્લેકની લિંક છે, એટલે કે ત્યાં કોઈ અન્ય મેસેન્જર નથી, પરંતુ હું ખરેખર અન્ય મેસેન્જર્સ માટે પણ સપોર્ટ કરવા માંગુ છું. તમે શું કરી શકો? તમે જૉ વિના DB લેબનો ઉપયોગ કરી શકો છો, REST APIની મદદથી અથવા અમારા પ્લેટફોર્મની મદદથી જઈ શકો છો અને ક્લોન્સ બનાવી શકો છો અને PSQL સાથે કનેક્ટ થઈ શકો છો. પરંતુ જો તમે તમારા વિકાસકર્તાઓને ડેટાની ઍક્સેસ આપવા માટે તૈયાર હોવ તો આ કરી શકાય છે, કારણ કે હવે કોઈ સ્ક્રીન હશે નહીં.

મને આ સ્તરની જરૂર નથી, પરંતુ મને આવી તકની જરૂર છે.

પછી હા, તે કરી શકાય છે.

સોર્સ: www.habr.com