ગૂગલ ક્લાઉડ સ્પેનર: ધ ગુડ, ધ બેડ એન્ડ ધ અગ્લી

હેલો, ખાબ્રોવસ્ક રહેવાસીઓ. હંમેશની જેમ, અમે નવા અભ્યાસક્રમોની શરૂઆત પહેલા રસપ્રદ સામગ્રી શેર કરવાનું ચાલુ રાખીએ છીએ. આજે, ખાસ કરીને તમારા માટે, અમે કોર્સની શરૂઆત સાથે સુસંગત રહેવા માટે Google Cloud Spanner વિશે એક લેખ પ્રકાશિત કર્યો છે. "વિકાસકર્તાઓ માટે AWS".

મૂળમાં પ્રકાશિત લાઇટસ્પીડ મુખ્ય મથક બ્લોગ.

વિશ્વભરના રિટેલર્સ, રેસ્ટોરેટર્સ અને ઓનલાઈન વિક્રેતાઓને ક્લાઉડ-આધારિત POS સોલ્યુશન્સ ઓફર કરતી કંપની તરીકે, Lightspeed વિવિધ પ્રકારના વ્યવહાર, વિશ્લેષણાત્મક અને શોધ ઉપયોગના કેસ માટે વિવિધ પ્રકારના ડેટાબેઝ પ્લેટફોર્મનો ઉપયોગ કરે છે. આ દરેક ડેટાબેઝ પ્લેટફોર્મની પોતાની શક્તિઓ અને નબળાઈઓ છે. આથી, જ્યારે Google એ ક્લાઉડ સ્પેનરને બજારમાં રજૂ કર્યું - રિલેશનલ ડેટાબેસેસની દુનિયામાં ન જોઈ શકાતી આશાસ્પદ સુવિધાઓ, જેમ કે વર્ચ્યુઅલ રીતે અમર્યાદિત આડી માપનીયતા અને 99,999% સેવા સ્તર કરાર (SLA), - અમે તેના પર હાથ મેળવવાની તક ગુમાવી શક્યા નહીં!

ક્લાઉડ સ્પેનર સાથેના અમારા અનુભવનું વ્યાપક વિહંગાવલોકન, તેમજ અમે ઉપયોગમાં લીધેલા મૂલ્યાંકન માપદંડો પ્રદાન કરવા માટે, અમે નીચેના વિષયોને આવરી લઈશું:

1. અમારા મૂલ્યાંકન માપદંડ
2. ટૂંકમાં ક્લાઉડ સ્પેનર
3. અમારું મૂલ્યાંકન
4. અમારા તારણો

1. અમારા મૂલ્યાંકન માપદંડ

ક્લાઉડ સ્પેનરની વિશિષ્ટતાઓમાં ડાઇવિંગ કરતા પહેલા, બજાર પરના અન્ય ઉકેલો સાથે તેની સમાનતા અને તફાવતો, ચાલો સૌપ્રથમ અમારા ઇન્ફ્રાસ્ટ્રક્ચરમાં ક્લાઉડ સ્પેનરને ક્યાં જમાવવું તે અંગે વિચારણા કરતી વખતે મુખ્ય ઉપયોગના કિસ્સાઓ વિશે વાત કરીએ:

• (મુખ્ય) પરંપરાગત SQL ડેટાબેઝ સોલ્યુશનના રિપ્લેસમેન્ટ તરીકે
• OLAP સપોર્ટ સાથે OLTP સોલ્યુશન કેવી રીતે કરવું

ઉદાહરણ: સરળતા અને સરખામણીમાં સરળતા માટે, આ લેખ ક્લાઉડ સ્પેનરની GCP ક્લાઉડ SQL અને Amazon AWS RDS સોલ્યુશન ફેમિલીના MySQL વેરિઅન્ટ સાથે સરખામણી કરે છે.

પરંપરાગત SQL ડેટાબેઝ સોલ્યુશનના રિપ્લેસમેન્ટ તરીકે ક્લાઉડ સ્પેનરનો ઉપયોગ કરવો

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

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

એપ્લિકેશનને વર્ટિકલી સ્કેલિંગ કરવાથી સર્વર ઇન્સ્ટન્સને અપગ્રેડ કરવામાં આવે છે, સામાન્ય રીતે વધુ પ્રોસેસર્સ/કોર, વધુ RAM, ઝડપી સ્ટોરેજ, વગેરે ઉમેરીને. વધુ હાર્ડવેર સંસાધનો ઉમેરવાથી ડેટાબેઝની કામગીરીમાં વધારો થાય છે, જે મુખ્યત્વે સેકન્ડમાં વ્યવહારોમાં માપવામાં આવે છે અને OLTP સિસ્ટમ્સ માટે ટ્રાન્ઝેક્શન લેટન્સી. રિલેશનલ ડેટાબેઝ સિસ્ટમ્સ (જે મલ્ટિ-થ્રેડેડ અભિગમનો ઉપયોગ કરે છે) જેમ કે MySQL સ્કેલ સારી રીતે ઊભી છે.

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

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

બીજી બાજુ, તેના સ્વભાવને કારણે, ક્લાઉડ સ્પેનર ન્યૂનતમ હસ્તક્ષેપ સાથે સરળતાથી આડા માપન કરી શકે છે.

સંપૂર્ણપણે ફીચર્ડ DBMS સેવા તરીકે વિવિધ ખૂણાઓથી મૂલ્યાંકન કરવું આવશ્યક છે. એક આધાર તરીકે, અમે ક્લાઉડમાં સૌથી વધુ લોકપ્રિય DBMS લીધું - Google, GCP Cloud SQL અને Amazon, AWS RDS માટે. અમારા મૂલ્યાંકનમાં અમે નીચેની શ્રેણીઓ પર ધ્યાન કેન્દ્રિત કર્યું:

• લક્ષણ મેપિંગ: હદ SQL, DDL, DML; કનેક્શન લાઇબ્રેરીઓ/કનેક્ટર્સ, ટ્રાન્ઝેક્શન સપોર્ટ, વગેરે.
• વિકાસ આધાર: સરળ વિકાસ અને પરીક્ષણ.
• એડમિનિસ્ટ્રેશન સપોર્ટ: ઇન્સ્ટન્સ મેનેજમેન્ટ - ઉદાહરણ તરીકે, સ્કેલિંગ અપ/ડાઉન અને ઇન્સ્ટન્સ અપગ્રેડ કરવું; SLA, બેકઅપ અને પુનઃપ્રાપ્તિ; સુરક્ષા/એક્સેસ નિયંત્રણ.

OLAP-સક્ષમ OLTP સોલ્યુશન તરીકે ક્લાઉડ સ્પેનરનો ઉપયોગ કરવો

જ્યારે Google સ્પષ્ટપણે એવો દાવો કરતું નથી કે ક્લાઉડ સ્પેનર વિશ્લેષણાત્મક પ્રક્રિયા માટે રચાયેલ છે, તે અન્ય એન્જિનો જેમ કે Apache Impala & Kudu અને YugaByte સાથે કેટલીક વિશેષતાઓ શેર કરે છે, જે OLAP વર્કલોડ માટે રચાયેલ છે.

જો ક્લાઉડ સ્પેનરમાં (વધુ કે ઓછા) ઉપયોગી OLAP ફીચર સેટ સાથે સાતત્યપૂર્ણ સ્કેલ-આઉટ HTAP (હાઇબ્રિડ ટ્રાન્ઝેક્શનલ/એનાલિટિક્સ પ્રોસેસિંગ) એન્જિનનો સમાવેશ થાય તેવી થોડી તક હોય તો પણ અમને લાગે છે કે તે અમારા ધ્યાનને પાત્ર હશે.

આને ધ્યાનમાં રાખીને, અમે નીચેની શ્રેણીઓ જોઈ:

• ડેટા લોડિંગ, ઇન્ડેક્સ અને પાર્ટીશન સપોર્ટ
• ક્વેરી પરફોર્મન્સ અને DML

2. ટૂંકમાં ક્લાઉડ સ્પેનર

Google Spanner એ ક્લસ્ટર્ડ રિલેશનલ ડેટાબેઝ મેનેજમેન્ટ સિસ્ટમ (RDBMS) છે જેનો ઉપયોગ Google તેની પોતાની કેટલીક સેવાઓ માટે કરે છે. ગૂગલે તેને સામાન્ય રીતે 2017ની શરૂઆતમાં Google ક્લાઉડ પ્લેટફોર્મ વપરાશકર્તાઓ માટે ઉપલબ્ધ કરાવ્યું હતું.

અહીં ક્લાઉડ સ્પેનરની કેટલીક વિશેષતાઓ છે:

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

"ક્લાઉડ સ્પેનર ફક્ત દુર્લભ કિસ્સાઓમાં જ આપમેળે ઇન્ડેક્સ પસંદ કરે છે. ખાસ કરીને, ક્લાઉડ સ્પેનર આપમેળે ગૌણ અનુક્રમણિકા પસંદ કરતું નથી જો કોઈ ક્વેરી કોઈપણ કૉલમની વિનંતી કરે છે જે સંગ્રહિત નથી અનુક્રમણિકા ».

• સર્વિસ લેવલ એગ્રીમેન્ટ (SLA): 99,99% ના SLA સાથે એક પ્રદેશમાં જમાવટ; 99,999% SLA સાથે બહુ-પ્રાદેશિક જમાવટ. જ્યારે SLA પોતે માત્ર એક કરાર છે અને કોઈપણ પ્રકારની બાંયધરી નથી, હું માનું છું કે Google ના લોકો પાસે આવો મજબૂત દાવો કરવા માટે કેટલાક સખત ડેટા છે. (સંદર્ભ માટે, 99,999% એટલે દર મહિને 26,3 સેકન્ડની સેવા અનુપલબ્ધતા.)
• વધુ https://cloud.google.com/spanner/

ઉદાહરણ: Apache Tephra પ્રોજેક્ટ Apache HBase (હવે બીટા તરીકે અપાચે ફોનિક્સમાં પણ અમલમાં છે) માટે ઉન્નત ટ્રાન્ઝેક્શન સપોર્ટ ઉમેરે છે.

3. અમારું મૂલ્યાંકન

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

અમે Sharded MySQL ના રિપ્લેસમેન્ટ તરીકે ક્લાઉડ સ્પેનરનું મૂલ્યાંકન કર્યું છે

Google Cloud SQL અને Amazon AWS RDS, ક્લાઉડ માર્કેટમાં સૌથી વધુ લોકપ્રિય OLTP DBMSs પૈકીના બે, લક્ષણોનો ખૂબ મોટો સમૂહ ધરાવે છે. જો કે, આ ડેટાબેસેસને એક નોડના માપથી આગળ માપવા માટે, તમારે એપ્લિકેશન પાર્ટીશન કરવાની જરૂર છે. આ અભિગમ એપ્લિકેશન અને વહીવટ બંને માટે વધારાની જટિલતા બનાવે છે. અમે જોયું કે સ્પેનર એક જ ઉદાહરણમાં બહુવિધ શાર્ડ્સને સંયોજિત કરવાના દૃશ્યમાં કેવી રીતે બંધબેસે છે અને કઈ સુવિધાઓ (જો કોઈ હોય તો) બલિદાન આપવાની જરૂર પડી શકે છે.

SQL, DML અને DDL સપોર્ટ, તેમજ કનેક્ટર અને લાઇબ્રેરીઓ?

પ્રથમ, કોઈપણ ડેટાબેઝ સાથે પ્રારંભ કરતી વખતે, તમારે ડેટા મોડેલ બનાવવાની જરૂર છે. જો તમને લાગે કે તમે તમારા મનપસંદ SQL ટૂલ સાથે JDBC સ્પેનરને કનેક્ટ કરી શકો છો, તો તમે જોશો કે તમે તેની સાથે તમારા ડેટાને ક્વેરી કરી શકો છો, પરંતુ તમે તેનો ઉપયોગ ટેબલ બનાવવા અથવા સંશોધિત (DDL) અથવા કોઈપણ દાખલ/અપડેટ/ડિલીટ કરવા માટે કરી શકતા નથી. કામગીરી (ડીએમએલ). Google નું અધિકૃત JDBC આ બંનેમાંથી કોઈને સમર્થન કરતું નથી.

"ડ્રાઇવર્સ હાલમાં DML અથવા DDL સ્ટેટમેન્ટને સપોર્ટ કરતા નથી."
સ્પેનર દસ્તાવેજીકરણ

GCP કન્સોલ સાથે પરિસ્થિતિ વધુ સારી નથી - તમે ફક્ત SELECT ક્વેરીઝ મોકલી શકો છો. સદભાગ્યે, વ્યવહારો સહિત, સમુદાયમાંથી DML અને DDL માટે સમર્થન સાથે JDBC ડ્રાઇવર છે github.com/olavloite/spanner-jdbc. જ્યારે આ ડ્રાઈવર અત્યંત ઉપયોગી છે, ત્યારે ગૂગલના પોતાના જેડીબીસી ડ્રાઈવરનો અભાવ આશ્ચર્યજનક છે. સદભાગ્યે, Google ક્લાયંટ લાઇબ્રેરીઓ (gRPC પર આધારિત): C#, Go, Java, node.js, PHP, Python અને Ruby માટે એકદમ વ્યાપક સમર્થન આપે છે.

ક્લાઉડ સ્પેનર કસ્ટમ API નો લગભગ ફરજિયાત ઉપયોગ (JDBC માં DDL અને DML ના અભાવને કારણે) સંબંધિત કોડ વિસ્તારો જેમ કે કનેક્શન પૂલ અથવા ડેટાબેઝ બંધનકર્તા ફ્રેમવર્ક (દા.ત. સ્પ્રિંગ MVC) માટે કેટલીક મર્યાદાઓમાં પરિણમે છે. સામાન્ય રીતે, JDBC નો ઉપયોગ કરતી વખતે, તમે તમારા મનપસંદ કનેક્શન પૂલને પસંદ કરવા માટે સ્વતંત્ર છો (દા.ત. HikariCP, DBCP, C3PO, વગેરે.) કે જે ચકાસાયેલ છે અને સારી રીતે કાર્ય કરે છે. કસ્ટમ સ્પેનર API ના કિસ્સામાં, આપણે ફ્રેમવર્ક/બંધનકર્તા પૂલ/સત્રો પર આધાર રાખવો પડશે જે આપણે જાતે બનાવેલ છે.

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

• તમે પ્રાથમિક કી મૂલ્યને અપડેટ કરી શકતા નથી; તમારે પહેલા મૂળ પીસીમાંથી એન્ટ્રી ડિલીટ કરવી પડશે અને તેને નવી કિંમત સાથે ફરીથી દાખલ કરવી પડશે. (આ અન્ય પીસી ઓરિએન્ટેડ ડેટાબેઝ/સ્ટોરેજ એન્જિન જેવું જ છે.)
• કોઈપણ અપડેટ અને ડિલીટ સ્ટેટમેન્ટમાં PC નો ઉલ્લેખ કરવો આવશ્યક છે, તેથી બધા સ્ટેટમેન્ટ્સ કાઢી નાખો ખાલી હોઈ શકે નહીં - ત્યાં હંમેશા સબક્વેરી હોવી જોઈએ, ઉદાહરણ તરીકે: અપડેટ xxx જ્યાં આઈડી ઇન (કોષ્ટક1માંથી આઈડી પસંદ કરો)
• ઓટો-ઇન્ક્રીમેન્ટ વિકલ્પનો અભાવ અથવા પીસી ફીલ્ડ માટે ક્રમ સુયોજિત કરતી સમાન કંઈપણ. આ કામ કરવા માટે, અનુરૂપ મૂલ્ય એપ્લિકેશન બાજુ પર બનાવવું આવશ્યક છે.

ગૌણ અનુક્રમણિકાઓ?

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

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

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

પ્રતિનિધિત્વ?

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

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

વિકાસ આધાર?

ક્લાઉડ સ્પેનર તેના API સાથે કામ કરવા માટે ખૂબ જ યોગ્ય પ્રોગ્રામિંગ ભાષા સપોર્ટ પ્રદાન કરે છે. અધિકૃત રીતે સમર્થિત પુસ્તકાલયો C#, Go, Java, node.js, PHP, Python અને Ruby ના વિસ્તારોમાં છે. દસ્તાવેજીકરણ ખૂબ વિગતવાર છે, પરંતુ અન્ય અદ્યતન તકનીકોની જેમ, સૌથી વધુ લોકપ્રિય ડેટાબેઝ તકનીકોની તુલનામાં સમુદાય ખૂબ નાનો છે, જે ઓછા સામાન્ય ઉપયોગના કિસ્સાઓ અથવા સમસ્યાઓને ઉકેલવામાં વધુ સમય પસાર કરી શકે છે.

તો સ્થાનિક વિકાસને ટેકો આપવા વિશે શું?

અમને ઑન-પ્રિમિસીસમાં ક્લાઉડ સ્પેનર ઇન્સ્ટન્સ બનાવવાનો કોઈ રસ્તો મળ્યો નથી. અમને સૌથી નજીકની વસ્તુ ડોકર ઇમેજ મળી. કોકરોચડીબી, જે સિદ્ધાંતમાં સમાન છે, પરંતુ વ્યવહારમાં ખૂબ જ અલગ છે. ઉદાહરણ તરીકે, CockroachDB PostgreSQL JDBC નો ઉપયોગ કરી શકે છે. વિકાસ પર્યાવરણ શક્ય તેટલું ઉત્પાદન પર્યાવરણની નજીક હોવું જોઈએ, ક્લાઉડ સ્પેનર આદર્શ નથી કારણ કે તે સંપૂર્ણ સ્પેનર ઉદાહરણ પર આધાર રાખે છે. ખર્ચ બચાવવા માટે, તમે સિંગલ-રિજન ઇન્સ્ટન્સ પસંદ કરી શકો છો.

એડમિનિસ્ટ્રેશન સપોર્ટ?

ક્લાઉડ સ્પેનર ઇન્સ્ટન્સ બનાવવું ખૂબ જ સરળ છે. તમારે ફક્ત બહુ-પ્રદેશ અથવા સિંગલ-રિજન ઇન્સ્ટન્સ બનાવવા વચ્ચે પસંદ કરવાની જરૂર છે, પ્રદેશ(ઓ) અને નોડ્સની સંખ્યાનો ઉલ્લેખ કરો. એક મિનિટ કરતાં ઓછા સમયમાં, તમારો દાખલો ચાલુ થઈ જશે.

Google કન્સોલમાં સ્પેનર પેજ પરથી કેટલાક પ્રાથમિક મેટ્રિક્સ સીધા જ ઍક્સેસિબલ છે. Stackdriver દ્વારા વધુ વિગતવાર દૃશ્યો ઉપલબ્ધ છે, જ્યાં તમે મેટ્રિક થ્રેશોલ્ડ અને ચેતવણી નીતિઓ પણ સેટ કરી શકો છો.

સંસાધનોની ઍક્સેસ?

MySQL વપરાશકર્તા પરવાનગીઓ/ભૂમિકાઓ માટે વ્યાપક અને અત્યંત દાણાદાર સેટિંગ્સ પ્રદાન કરે છે. તમે ચોક્કસ કોષ્ટકની ઍક્સેસને સરળતાથી ગોઠવી શકો છો, અથવા તો તેના કૉલમના સબસેટને પણ. ક્લાઉડ સ્પેનર Google ના આઇડેન્ટિટી એન્ડ એક્સેસ મેનેજમેન્ટ (IAM) ટૂલનો ઉપયોગ કરે છે, જે તમને માત્ર ખૂબ જ ઉચ્ચ સ્તરે નીતિઓ અને પરવાનગીઓ સેટ કરવાની મંજૂરી આપે છે. સૌથી દાણાદાર વિકલ્પ એ ડેટાબેઝ-લેવલ રિઝોલ્યુશન છે, જે મોટાભાગના ઉત્પાદન ઉપયોગના કેસોમાં બંધ બેસતું નથી. આ મર્યાદા તમને સ્પેનર સંસાધનોના અનધિકૃત ઉપયોગને રોકવા માટે તમારા કોડ, ઇન્ફ્રાસ્ટ્રક્ચર અથવા બંનેમાં વધારાના સુરક્ષા પગલાં ઉમેરવા દબાણ કરે છે.

બેકઅપ?

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

ક્વેરી કામગીરી?

અમે ડેટા લોડ કરવા અને પ્રશ્નોના પરીક્ષણ માટે Yahoo! ક્લાઉડ સર્વિંગ બેન્ચમાર્ક. નીચેનું કોષ્ટક YCSB વર્કલોડ B બતાવે છે જેમાં 95% વાંચનથી 5% લેખન ગુણોત્તર છે.

* લોડ ટેસ્ટ n1-સ્ટાન્ડર્ડ-32 કોમ્પ્યુટ એન્જીન (CE) (32 vCPU, 120 GB મેમરી) પર ચલાવવામાં આવ્યો હતો, અને પરીક્ષણનો દાખલો ક્યારેય પરીક્ષણોમાં અડચણરૂપ ન હતો.
** એક YCSB ઇન્સ્ટન્સમાં થ્રેડોની મહત્તમ સંખ્યા 400 છે. કુલ 2400 થ્રેડો મેળવવા માટે YCSB ટેસ્ટના કુલ છ સમાંતર દાખલાઓ ચલાવવાની હતી.

બેન્ચમાર્ક પરિણામોને જોતા, ખાસ કરીને CPU લોડ અને TPS ના સંયોજનને, અમે સ્પષ્ટપણે જોઈ શકીએ છીએ કે ક્લાઉડ સ્પેનર ખૂબ સારી રીતે સ્કેલ કરે છે. મોટી સંખ્યામાં થ્રેડો દ્વારા બનાવેલ ભારે ભારને ક્લાઉડ સ્પેનર ક્લસ્ટરમાં મોટી સંખ્યામાં નોડ્સ દ્વારા સરભર કરવામાં આવે છે. જ્યારે લેટન્સી ખૂબ ઊંચી દેખાય છે, ખાસ કરીને જ્યારે 2400 થ્રેડો સાથે ચાલતી હોય, ત્યારે વધુ સચોટ નંબરો મેળવવા માટે કમ્પ્યુટ એન્જિનના 6 નાના ઉદાહરણો સાથે ફરીથી પરીક્ષણ કરવું જરૂરી હોઈ શકે છે. દરેક ઉદાહરણ 6 સમાંતર પરીક્ષણો સાથે એક મોટા CE દાખલાને બદલે એક YCSB પરીક્ષણ ચલાવશે. આ રીતે, ક્લાઉડ સ્પેનર વિનંતી લેટન્સી અને ક્લાઉડ સ્પેનર અને પરીક્ષણ ચલાવતા CE ઉદાહરણ વચ્ચે નેટવર્ક કનેક્શન દ્વારા ઉમેરવામાં આવેલ વિલંબતા વચ્ચે તફાવત કરવો સરળ બનશે.

ક્લાઉડ સ્પેનર OLAP તરીકે કેવી રીતે કાર્ય કરે છે?

પાર્ટીશન?

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

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

ડેટા લોડ કરી રહ્યાં છીએ?

બલ્ક ડેટા માટેની ક્લાઉડ સ્પેનર પદ્ધતિ સામાન્ય લોડિંગ માટે સમાન છે. મહત્તમ પ્રભાવ હાંસલ કરવા માટે, તમારે કેટલીક દિશાનિર્દેશોનું પાલન કરવાની જરૂર છે, જેમાં નીચેનાનો સમાવેશ થાય છે:

• પ્રાથમિક કી દ્વારા તમારા ડેટાને સૉર્ટ કરો.
• તેમને 10* વડે વિભાજીત કરોગાંઠોની સંખ્યા અલગ વિભાગો.
• કામના કાર્યોનો સમૂહ બનાવો જે ડેટાને સમાંતર લોડ કરે છે.

આ ડેટા લોડિંગ તમામ ક્લાઉડ સ્પેનર નોડ્સનો ઉપયોગ કરે છે.

અમે 10M પંક્તિઓનો ડેટાસેટ બનાવવા માટે YCSB વર્કલોડ A નો ઉપયોગ કર્યો.

* લોડ ટેસ્ટ n1-સ્ટાન્ડર્ડ-32 કમ્પ્યુટ એન્જીન (32 vCPU, 120 GB મેમરી) પર ચલાવવામાં આવ્યો હતો, અને ટેસ્ટનો દાખલો ક્યારેય પરીક્ષણોમાં અડચણરૂપ ન હતો.
**કોઈપણ પ્રોડક્શન વર્કલોડ માટે સિંગલ નોડ સેટઅપની ભલામણ કરવામાં આવતી નથી.

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

સ્કેલિંગ?

ક્લાઉડ સ્પેનર નોડ્સની સંખ્યા વધારવી અને ઘટાડવી એ એક-ક્લિક કાર્ય છે. જો તમે ઝડપથી ડેટા લોડ કરવા માંગતા હો, તો તમે તમારા દાખલાને મહત્તમ સુધી વધારવાનું વિચારી શકો છો (અમારા કિસ્સામાં તે યુએસ-પૂર્વ પ્રદેશમાં 25 નોડ્સ હતા) અને પછી એકવાર બધો ડેટા આવી જાય તે પછી તમારા સામાન્ય લોડ માટે લાયક નોડ્સની સંખ્યા ઘટાડવી. ડેટાબેઝ, 2TB/નોડ મર્યાદાનો ઉલ્લેખ કરે છે.

ઘણા નાના ડેટાબેઝ સાથે પણ અમને આ મર્યાદાની યાદ અપાવી હતી. લોડ પરીક્ષણોના ઘણા રન પછી, અમારું ડેટાબેઝ લગભગ 155 GB નું કદ હતું, અને જ્યારે 1 નોડના દાખલામાં સ્કેલ કરવામાં આવ્યું ત્યારે, અમને નીચેની ભૂલ મળી:

અમે 25 થી 2 દાખલાઓને સ્કેલ કરવામાં વ્યવસ્થાપિત થયા, પરંતુ અમે બે ગાંઠો પર અટવાઈ ગયા.

ક્લાઉડ સ્પેનર ક્લસ્ટરમાં નોડ્સની સંખ્યામાં વધારો અને ઘટાડો REST API નો ઉપયોગ કરીને સ્વચાલિત થઈ શકે છે. આ ખાસ કરીને વ્યસ્ત કામના કલાકો દરમિયાન વધેલા સિસ્ટમ લોડને ઘટાડવા માટે ઉપયોગી થઈ શકે છે.

OLAP પ્રશ્નોનું પ્રદર્શન?

અમે મૂળરૂપે આ ભાગ પર સ્પેનરના અમારા મૂલ્યાંકનમાં નોંધપાત્ર સમય પસાર કરવાનું આયોજન કર્યું હતું. ઘણા સિલેક્ટ કાઉન્ટ્સ પછી, અમને તરત જ સમજાયું કે પરીક્ષણ ટૂંકું હશે અને સ્પેનર OLAP માટે યોગ્ય એન્જિન નહીં હોય. ક્લસ્ટરમાં નોડ્સની સંખ્યાને ધ્યાનમાં લીધા વિના, 10M પંક્તિ કોષ્ટકમાં પંક્તિઓની સંખ્યા પસંદ કરવામાં 55 થી 60 સેકન્ડનો સમય લાગ્યો. વધુમાં, કોઈપણ ક્વેરી કે જેને મધ્યવર્તી પરિણામો સંગ્રહિત કરવા માટે વધુ મેમરીની જરૂર હોય તે OOM ભૂલ સાથે નિષ્ફળ ગઈ.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

TPC-H પ્રશ્નો માટેના કેટલાક નંબરો ટોડ લિપકોનના લેખમાં મળી શકે છે Nosql-kudu-spanner-slides.html, સ્લાઇડ્સ 42 અને 43. આ સંખ્યાઓ આપણા પોતાના પરિણામો સાથે સુસંગત છે (કમનસીબે).

4. અમારા તારણો

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

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

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

વાજબી બનવા માટે, ક્લાઉડ સ્પેનર ફક્ત 2017 ની વસંતમાં જ જાહેર જનતા માટે રિલીઝ કરવામાં આવ્યું હતું, તેથી તે અપેક્ષા રાખવી વાજબી છે કે તેની વર્તમાન ખામીઓમાંથી કેટલીક આખરે દૂર થઈ શકે છે (આશા છે), અને જ્યારે તેઓ કરે છે, ત્યારે તે ગેમ ચેન્જર બની શકે છે. છેવટે, Cloud Spanner એ Google માટે માત્ર એક બાજુનો પ્રોજેક્ટ નથી. Google તેનો ઉપયોગ અન્ય Google ઉત્પાદનો માટે આધાર તરીકે કરે છે. અને જ્યારે ગૂગલે તાજેતરમાં મેગાસ્ટોરને ગૂગલ ક્લાઉડ સ્ટોરેજમાં ક્લાઉડ સ્પેનર સાથે બદલ્યું, ત્યારે તેણે વૈશ્વિક સ્તરે ઑબ્જેક્ટ્સની સૂચિ માટે Google ક્લાઉડ સ્ટોરેજને અત્યંત સુસંગત બનવાની મંજૂરી આપી (જે હજી પણ આ કેસ માટે નથી. એમેઝોનના S3).

તેથી, હજુ પણ આશા છે... અમે આશા રાખીએ છીએ.

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

અમે દરેકને અમારી મુલાકાત લેવા આમંત્રિત કરીએ છીએ મફત વેબિનાર જેમાં અમે તમને કોર્સ વિશે વિગતવાર જણાવીશું "વિકાસકર્તાઓ માટે AWS" OTUS માંથી.

સોર્સ: www.habr.com