मैंने तीनों डेटाबेस के साथ काम किया है और उनके बीच माइग्रेशन किया है, इसलिए उम्मीद है कि मैं अभी भी एक पुरानी पोस्ट में कुछ जोड़ सकता हूं। दस साल पहले मुझे जीएमएल से एक स्थानिक डेटाबेस में एक लार्जिश - 450 मिलियन स्थानिक वस्तुओं - डेटासेट डालने का काम सौंपा गया था। मैंने MySQL और Postgis को आज़माने का फैसला किया, उस समय SQL सर्वर में कोई स्थानिक नहीं था और हमारे पास एक छोटा स्टार्टअप वातावरण था, इसलिए MySQL एक अच्छा फिट लग रहा था। मैं बाद में MySQL में शामिल हो गया, मैंने कुछ सम्मेलनों में भाग लिया/बात की और MySQL में अधिक GIS-अनुरूप कार्यों के बीटा परीक्षण में भारी रूप से शामिल था जो अंततः संस्करण 5.5 के साथ जारी किया गया था। मैं बाद में अपने स्थानिक डेटा को पोस्टगिस और हमारे कॉर्पोरेट डेटा (स्थानिक तत्वों के साथ) को SQL सर्वर में माइग्रेट करने में शामिल रहा हूं। ये मेरे निष्कर्ष हैं।
MySQL
1) । स्थिरता के मुद्दे। 5 वर्षों के दौरान, हमारे पास कई डेटाबेस भ्रष्टाचार मुद्दे थे, जिन्हें केवल इंडेक्स फ़ाइल पर myismachk चलाकर ठीक किया जा सकता था, एक प्रक्रिया जिसमें 450 मिलियन पंक्ति तालिका पर 24 घंटे से अधिक समय लग सकता है।
2))। कुछ समय पहले तक केवल MyISAM तालिकाओं ने स्थानिक डेटा प्रकार का समर्थन किया था। इसका मतलब है कि यदि आप लेन-देन का समर्थन चाहते हैं तो आप भाग्य से बाहर हैं। InnoDB तालिका प्रकार अब स्थानिक प्रकारों का समर्थन करता है, लेकिन उन पर अनुक्रमणिका नहीं, जो स्थानिक डेटा सेट के विशिष्ट आकार को देखते हुए, बहुत उपयोगी नहीं है। देखें http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html सम्मेलनों में जाने से मेरा अनुभव यह था कि स्थानिक बहुत बाद में सोचा गया था - हमने प्रतिकृति, विभाजन, आदि लागू किया है, लेकिन यह स्थानिक के साथ काम नहीं करता है। संपादित करें:आगामी 5.7.5 रिलीज में InnoDB अंततः स्थानिक स्तंभों पर अनुक्रमणिका का समर्थन करेगा, जिसका अर्थ है कि ACID, विदेशी कुंजी और स्थानिक अनुक्रमणिका अंततः एक ही इंजन में उपलब्ध होंगे।
3))। Postgis और SQL Server स्थानिक दोनों की तुलना में स्थानिक कार्यक्षमता अत्यंत सीमित है। अभी भी कोई ST_Union फ़ंक्शन नहीं है जो संपूर्ण ज्यामिति क्षेत्र पर कार्य करता है, एक प्रश्न जो मैं सबसे अधिक बार चलाता हूं, अर्थात, आप लिख नहीं सकते:
select attribute, ST_Union(geom) from some_table group by some_attribute
जो जीआईएस के संदर्भ में बहुत उपयोगी है। Select ST_Union(geom1, const_geom) from some_table , यानी, ज्यामिति में से एक हार्ड-कोडेड स्थिर ज्यामिति है जो तुलना में थोड़ी सीमित है।
4))। चूहों के लिए कोई समर्थन नहीं। एक डीबी के भीतर संयुक्त वेक्टर-रास्टर विश्लेषण करने में सक्षम होना बहुत उपयोगी जीआईएस कार्यक्षमता है।
5). एक स्थानिक संदर्भ प्रणाली से दूसरे में रूपांतरण के लिए कोई समर्थन नहीं।
6)। Oracle द्वारा अधिग्रहण के बाद से, स्थानिक वास्तव में रोक दिया गया है।
कुल मिलाकर, MySQL के लिए निष्पक्ष होने के लिए इसने कई वर्षों तक हमारी वेबसाइट, WMS और सामान्य स्थानिक प्रसंस्करण का समर्थन किया, और इसे स्थापित करना आसान था। नकारात्मक पक्ष पर, डेटा भ्रष्टाचार एक मुद्दा था, और MyISAM तालिकाओं का उपयोग करने के लिए मजबूर होने के कारण आप RDBMS के बहुत से लाभों को छोड़ रहे हैं।
पोस्टगिस
हमारे पास MySQL के साथ होने वाली समस्याओं को देखते हुए, हम अंततः पोस्टगिस में परिवर्तित हो गए। इस अनुभव के प्रमुख बिंदु रहे हैं।
1) । अत्यधिक स्थिरता। 5 वर्षों में कोई डेटा भ्रष्टाचार नहीं है और अब हमारे पास सेंटो वर्चुअल मशीनों पर लोड की अलग-अलग डिग्री के तहत लगभग 25 पोस्टग्रेज/जीआईएस बॉक्स हैं।
2))। विकास की तीव्र गति - रेखापुंज, टोपोलॉजी, 3D समर्थन इसके हालिया उदाहरण हैं।
3))। बहुत सक्रिय समुदाय। पोस्टगिस आईआरसी चैनल और मेलिंग सूची उत्कृष्ट संसाधन हैं। Postgis संदर्भ पुस्तिका भी उत्कृष्ट है। http://postgis.net/docs/manual-2.0/
4))। OSGeo छत्र के तहत अन्य अनुप्रयोगों के साथ बहुत अच्छा खेलता है, जैसे कि जियोसर्वर और GDAL।
5). डिफ़ॉल्ट plpgsql, जैसे कि Python या R के अलावा, संग्रहीत कार्यविधियाँ कई भाषाओं में लिखी जा सकती हैं।
5). Postgres एक बहुत ही मानकों के अनुरूप है, पूरी तरह से चित्रित RDBMS है, जिसका उद्देश्य ANSI मानकों के करीब रहना है।
6)। विंडो फ़ंक्शंस और पुनरावर्ती प्रश्नों के लिए समर्थन - MySQL में नहीं, बल्कि SQL सर्वर में। इसने लेखन को और अधिक जटिल स्थानिक प्रश्नों को क्लीनर बना दिया है।
एसक्यूएल सर्वर।
मैंने केवल SQL Server 2008 स्थानिक कार्यक्षमता का उपयोग किया है, और उस रिलीज़ की कई झुंझलाहट - एक CRS से दूसरे में रूपांतरण के लिए समर्थन की कमी, अपने स्वयं के मापदंडों को स्थानिक अनुक्रमणिका में जोड़ने की आवश्यकता - अब हल हो गई है।
1) । चूंकि SQL सर्वर में स्थानिक ऑब्जेक्ट मूल रूप से CLR ऑब्जेक्ट होते हैं, सिंटैक्स पीछे की ओर महसूस करता है। ST_Area(geom) के बजाय आप geom.STArea() लिखते हैं और यह तब और भी स्पष्ट हो जाता है जब आप एक साथ श्रृंखलाबद्ध कार्य करते हैं। फ़ंक्शन नामों में अंडरस्कोर का गिरना केवल एक छोटी सी झुंझलाहट है।
2))। मेरे पास कई अमान्य बहुभुज हैं जिन्हें SQL सर्वर द्वारा स्वीकार किया गया है, और ST_MakeValid फ़ंक्शन की कमी इसे थोड़ा दर्दनाक बना सकती है।
3))। केवल विंडोज़। सामान्य तौर पर, Microsoft उत्पादों (जैसे ESRI वाले) को एक-दूसरे के साथ बहुत अच्छी तरह से काम करने के लिए डिज़ाइन किया गया है, लेकिन प्राथमिक उद्देश्यों के रूप में हमेशा मानक अनुपालन और अंतःक्रियाशीलता नहीं होती है। यदि आप केवल विंडोज़ की दुकान चला रहे हैं, तो यह कोई समस्या नहीं है।
अपडेट करें :SQL सर्वर 2012 के साथ थोड़ा सा खेलने के बाद, मैं कह सकता हूं कि इसमें काफी सुधार हुआ है। अब एक अच्छा ज्यामिति सत्यापन कार्य है, भूगोल डेटा प्रकार के लिए अच्छा समर्थन है, जिसमें एक पूर्ण ग्लोब ऑब्जेक्ट भी शामिल है, जो एक से अधिक गोलार्ध पर कब्जा करने वाली वस्तुओं का प्रतिनिधित्व करने की अनुमति देता है और कंपाउंड कर्व्स और सर्कुलर स्ट्रिंग्स के लिए समर्थन करता है जो सटीक और कॉम्पैक्ट के लिए उपयोगी है। अन्य बातों के अलावा चापों (और वृत्तों) का निरूपण। निर्देशांक को एक CRS से दूसरे में बदलना अभी भी तृतीय पक्ष पुस्तकालयों में किए जाने की आवश्यकता है, हालांकि अधिकांश अनुप्रयोगों में यह शो स्टॉपर नहीं है।
मैंने पोस्टगिस/माईएसक्यूएल के साथ एक की तुलना करने के लिए बड़े पर्याप्त डेटासेट के साथ एसक्यूएल सर्वर का उपयोग नहीं किया है, लेकिन मैंने जो देखा है उससे फ़ंक्शन सही ढंग से व्यवहार करते हैं, और पोस्टगिस के रूप में पूरी तरह से प्रदर्शित नहीं होने पर, यह MySQL के प्रसाद पर एक बड़ा सुधार है ।
इतने लंबे उत्तर के लिए क्षमा करें, मुझे आशा है कि पिछले कुछ वर्षों में मैंने जो दर्द और खुशी झेली है, वह किसी के लिए मददगार हो सकती है।
