რომელი ბაზა გამოვიყენო? Postgres, MySQL, SQL Server

ახალი აპლიკაციისთვის, რომელსაც შეზღუდვები არ აქვს, გამოიყენე PostgreSQL. ის უფასოა ნებისმიერ ზომაზე, სტანდარტებს შეესაბამება, რელაციურ მონაცემებსა და JSON დოკუმენტებს თანაბრად კარგად უმკლავდება და ღია კოდის ბაზებს შორის extension-ების ყველაზე ღრმა ნაკრები აქვს. გამოიყენე MySQL, როცა პროგრამა, რომელსაც უშვებ, მას ელის - WordPress, PHP აპლიკაციების უმეტესობა, თამაშის სერვერების ბევრი plugin. გამოიყენე SQL Server, როცა .NET-ზე აშენებ გუნდთან ერთად, რომელმაც ის უკვე იცის, ან გადმოგეცა ბაზა, რომელიც უკვე არსებობს, და იცოდე, რომ უფასო Express გამოცემა თითო ბაზაზე 10 GB-ზე ჩერდება. გამოიყენე MongoDB, როცა შენი მონაცემები მართლა დოკუმენტის ფორმისაა და აპლიკაცია მის გარშემოა აგებული. და Valkey გამოიყენე რომელიმე მათგანის გვერდით და არა მათ ნაცვლად: ეს სწრაფი მეხსიერებაში მომუშავე საცავია cache-ებისთვის, სესიებისთვის, რიგებისთვის და rate limit-ებისთვის და არა მთავარი ბაზა.

ეს აბზაცი ადამიანების უმეტესობისთვის პასუხია. გზამკვლევის დანარჩენი ნაწილი მსჯელობას ხსნის, რომ შეძლო გაარჩიო, როდის არის შენი სიტუაცია გამონაკლისი.

მოკლე ვერსია, სამუშაოს მიხედვით#

ყველაზე მნიშვნელოვანი სვეტი მესამეა. ბაზებს იშვიათად ირჩევენ benchmark-ებით; მათ ირჩევს ის, რასაც შენი პროგრამა, შენი framework და შენი გუნდი უკვე გულისხმობს. ამასთან ბრძოლა უფრო ძვირი ჯდება, ვიდრე მათ შორის წარმადობის ნებისმიერი განსხვავება.

PostgreSQL: ნაგულისხმევი ახალი სამუშაოსთვის#

PostgreSQL ღია კოდის რელაციური ბაზაა ოცდაათწლიანი განვითარებით, თავისუფალი ლიცენზიით და ფასიანი გამოცემის გარეშე. მისი ძლიერი მხარეებია სიგანე და სისწორე: ტრანზაქციული DDL (ჩავარდნილი მიგრაცია სუფთად ბრუნდება უკან), მდიდარი ტიპები (მასივები, დიაპაზონები, jsonb, ქსელური მისამართები), სათანადო CHECK შეზღუდვები, window ფუნქციები, common table expression-ები, ნაწილობრივი და გამოსახულებაზე აგებული ინდექსები, და extension-ების სისტემა, რომელიც მთელ შესაძლებლობებს ამატებს - PostGIS გეოგრაფიისთვის, pg_trgm ბუნდოვანი ტექსტური ძებნისთვის, pgvector embedding-ებისთვის, TimescaleDB დროითი მწკრივებისთვის.

jsonb განსაკუთრებულ ხსენებას იმსახურებს, რადგან ის აქრობს ყველაზე გავრცელებულ მიზეზს, რის გამოც ხალხი MongoDB-ს მიმართავს. შეგიძლია დოკუმენტი სვეტში შეინახო, მის შიგნით GIN ინდექსით ინდექსირება გააკეთო, ოპერატორებით query გაუშვა და მაინც ჩვეულებრივ ცხრილებთან join გააკეთო იმავე ტრანზაქციაში.

ხარჯები ცნობილი და სამართავია. ყოველი კავშირი ოპერაციული სისტემის ცალკე პროცესია, ამიტომ ასობით უმოქმედო კავშირი რეალურ მეხსიერებას ჯდება, და აპლიკაციას ბევრი worker-ით connection pooler სჭირდება - connection pool-ები და ლიმიტები ამას განიხილავს. მისი მრავალვერსიიანი დიზაინი ტოვებს მკვდარ row-ებს, რომლებიც autovacuum-მა უნდა გაწმინდოს, რაც ხშირად განახლებად ცხრილებზე ცოტა ყურადღებას მოითხოვს. არცერთი არ არის მიზეზი, სხვა რამე აირჩიო; ორივე ისაა, რაც პირველ თვეში უნდა გაიგო.

თუ კონკრეტულად PostgreSQL-სა და მის ორ უახლოეს კონკურენტს შორის ირჩევ, MySQL vs PostgreSQL და Postgres თუ MongoDB უფრო ღრმად შედის.

MySQL: როცა პროგრამა მას ელის#

MySQL ვებში ყველაზე ფართოდ გავრცელებული ღია კოდის ბაზაა, დიდწილად იმიტომ, რომ PHP მასთან ერთად გაიზარდა. WordPress, Drupal, Joomla, Magento, phpBB და PHP აპლიკაციების დიდი უმრავლესობა პირველ რიგში MySQL-ისთვის იწერება. თამაშის სერვერების სამყაროში უფლებების plugin-ები, ეკონომიკის plugin-ები და framework-ები, როგორიცაა FiveM-ის oxmysql, ყველა MySQL-ს ელის. ამ პროგრამის სხვა რამეზე გაშვება მხარდაუჭერლიდან შეუძლებლამდე მერყეობს.

თანამედროვე MySQL შესაძლებლობებით სავსე ბაზაა. InnoDB ათ წელზე მეტია ნაგულისხმევი ძრავაა, ტრანზაქციებით, foreign key-ებით და crash-ისგან დაცვით. MySQL 8-მა დაამატა window ფუნქციები, common table expression-ები, სათანადო data dictionary და გაცილებით უკეთესი JSON მხარდაჭერა. MySQL 8.4 გრძელვადიანი მხარდაჭერის რელიზია, რაც მნიშვნელოვანია ბაზისთვის, რომლის ყოველ კვარტალში განახლებაც არ გინდა; მან ასევე ნაგულისხმევად გამორთო ძველი mysql_native_password ავთენტიფიკაციის plugin, რაც მთავარია იმისა, რაც მასთან დაკავშირებულ ძველ კლიენტებს ტეხავს. MySQL 8.4 LTS: რა შეიცვალა დეტალებს შეიცავს.

სადაც MySQL PostgreSQL-ზე სუსტია, ეს კუთხეებია: ნაკლები ინდექსის ტიპი, CHECK შეზღუდვების სუსტი ისტორია, DDL, რომელიც ტრანზაქციული არ არის, და ისტორიული ნაგულისხმევების გრძელი კუდი - კლასიკური მაგალითია სამბაიტიანი utf8 სიმბოლოების ნაკრები - რომლის თავიდან არიდებაც ახალმა პროექტებმა უნდა იცოდნენ. ყველგან გამოიყენე utf8mb4. პროგრამისთვის, რომელიც MySQL-ს ელის, ამას არ აქვს მნიშვნელობა; იყენებ MySQL-ს. ახალი აპლიკაციისთვის თავისუფალი არჩევანით კი ეს ის მიზეზია, რის გამოც PostgreSQL ჩვეულებრივ იმარჯვებს.

SQL Server: .NET, არსებული ინფრასტრუქტურა და Express-ის ჭერი#

SQL Server Microsoft-ის რელაციური ბაზაა და 2017-დან Linux-ზეც მუშაობს და არა მხოლოდ Windows-ზე. მისი ძლიერი მხარეებია ინსტრუმენტები და ინტეგრაცია. SQL Server Management Studio ჯერ კიდევ საუკეთესო უფასო ბაზის GUI-ა, query-ის ოპტიმიზატორი შესანიშნავია, execution plan-ები და Query Store წარმადობაზე მუშაობას უჩვეულოდ ხილულს ხდის, მთელი .NET სტეკი კი - Microsoft.Data.SqlClient, Entity Framework Core, ASP.NET Core Identity - მას საკუთარ ბაზად მიიჩნევს. T-SQL ძლიერი პროცედურული ენაა, და გუნდი, რომელმაც ის იცის, მასში პროდუქტიულია. T-SQL-ის საფუძვლები დეველოპერებისთვის განიხილავს, რით განსხვავდება ის ღია კოდის ძრავებისგან.

უფასო გამოცემა Express-ია, და მისი ლიმიტები მთელი გადაწყვეტილებაა:

ძალიან ბევრი აპლიკაციისთვის - შიდა ინსტრუმენტი, ბიზნეს-აპლიკაცია, პატარა SaaS, სათამაშო საზოგადოების ვებსაიტი - 10 GB წლების მონაცემებია, და Express კარგი production ბაზაა. რისკი ისაა, რა ხდება, როცა მას გადაიზრდები. შემდეგი ნაბიჯი Standard გამოცემაა, რომელიც ბირთვზე ლიცენზირდება და ნამდვილ ფულს ჯდება, ამ სიის ყველა სხვა ბაზისგან განსხვავებით. აირჩიე SQL Server მისი ინსტრუმენტებისა და შენი გუნდის გამო და არა ნაგულისხმევად, და გადაწყვეტამდე პატიოსნად შეაფასე შენი მონაცემების ზრდა. SQL Server Express ჰოსტინგი განიხილავს, სად იკბინება ჭერი.

თუ .NET-ზე ხარ არსებული SQL Server-ის გარეშე, PostgreSQL Npgsql-ით თანაბრად პირველი კლასის არჩევანია ჭერის გარეშე. .NET PostgreSQL-ით, MySQL-ით თუ SQL Server-ით provider-ებს ადარებს.

MongoDB: როცა მონაცემები მართლა დოკუმენტებია#

MongoDB JSON-ის მსგავს დოკუმენტებს (BSON) collection-ებში ინახავს, ფიქსირებული სქემის გარეშე. ის უხდება მონაცემებს, რომლებიც ბუნებრივად ჩადგმულია და მთლიანად იკითხება - პროდუქტი ცვალებადი ატრიბუტებით, მომხმარებლის პროფილი ჩაშენებული პარამეტრებით, მოვლენის payload - და აპლიკაციებს, რომლებიც ფორმას სწრაფად იცვლიან. მისი aggregation pipeline ძლიერია, დრაივერები სასიამოვნოა, და ჰორიზონტალური მასშტაბირება sharding-ით ჩაშენებულია, თუმცა მცირე პროექტების ცოტას თუ დასჭირდება ოდესმე.

ფასი ჩანს, როცა აღმოჩნდება, რომ მონაცემები მაინც რელაციურია. Join-ები არსებობს ($lookup), მაგრამ ეს ის არ არის, რაშიც MongoDB კარგია, ამიტომ მონაცემები, რომლებსაც ბევრი ერთეული იზიარებს, ყოველ დოკუმენტში დუბლირდება და მერე სინქრონიზაციაში უნდა შენარჩუნდეს. მრავალდოკუმენტიანი ტრანზაქციები MongoDB 4.0-დან არსებობს, მაგრამ მხოლოდ replica set-ზე ან sharded კლასტერზე: ერთი დამოუკიდებელი mongod მათ მხარს არ უჭერს, რაც მნიშვნელოვანია, თუ მათზე ითვლი. და „სქემის გარეშე“ პრაქტიკაში ნიშნავს, რომ სქემა შენს აპლიკაციის კოდში ცხოვრობს, სადაც მისი დანახვა და აღსრულება უფრო რთულია - collection-ებზე ვალიდაციის წესები გეხმარება.

სასარგებლო ტესტი: ჩამოწერე ის ხუთი query, რომელსაც შენი აპლიკაცია ყველაზე ხშირად უშვებს. თუ მათი უმეტესობა ერთ დოკუმენტს გასაღებით იღებს და აჩვენებს, MongoDB კარგად ერგება. თუ მათი უმეტესობა რამდენიმე სახის ობიექტზე join-ს ან აგრეგაციას აკეთებს, გამოიყენე PostgreSQL და ნამდვილად ცვალებადი ნაწილები jsonb-ში მოათავსე. MongoDB-ის ინდექსები და სქემის დიზაინი პირველი შემთხვევისთვის დიზაინს განიხილავს.

Valkey: მეორე ბაზა და არა პირველი#

Valkey მეხსიერებაში მომუშავე key-value საცავია, რომელიც Redis-იდან 2024-ში გამოიყო მას შემდეგ, რაც Redis-მა ლიცენზია შეცვალა, და თავსებადია Redis-ის პროტოკოლთან, ბრძანებებთან და კლიენტის ბიბლიოთეკებთან. ყველაფერი მეხსიერებაში ცხოვრობს, რაც წაკითხვასა და ჩაწერას მიკროწამებად აქცევს, და ის გთავაზობს მონაცემთა სტრუქტურებს - hash-ები, სიები, სიმრავლეები, დალაგებული სიმრავლეები, stream-ები - რომლებიც პირდაპირ ერგება გავრცელებულ პრობლემებს:

• Cache query-ების შედეგებისთვის ან დარენდერებული ფრაგმენტებისთვის TTL-ით.
• სესიები ვებ-აპლიკაციებისთვის, გაზიარებული აპლიკაციის რამდენიმე პროცესს შორის.
• რიგები ფონური job-ებისთვის, ისეთი ბიბლიოთეკებით, როგორიცაა BullMQ, Celery და Sidekiq.
• Rate limiting ატომური მთვლელებით, რომლებსაც ვადა გასდით.
• Leaderboard-ები დალაგებული სიმრავლეებით.
• Pub/sub პროცესებს შორის მოვლენების გასაგზავნად.

მას შეუძლია დისკზე შენახვა snapshot-ებითა და append-only ფაილით, ამიტომ restart-ს გადაურჩება, მაგრამ მისი მონაცემების მოცულობა მეხსიერებით არის შეზღუდული, query-ის ენა არ აქვს, და ის ისეა დაპროექტებული, რომ cache-ის გაქრობისას მნიშვნელოვანი არაფერი დაიკარგოს. მიიჩნიე ის ადგილად მონაცემებისთვის, რომელთა ხელახლა აგებაც შეგიძლია ან რომელთა დაკარგვაც შეგიძლია, რელაციური ბაზის გვერდით, რომელიც სიმართლეს ინახავს. Redis: როდის გჭირდება ასაბუთებს მის დამატებას და მის წინააღმდეგაც, Valkey vs Redis ახსნილი კი fork-ს განიხილავს.

რა წყვეტს სინამდვილეში#

როცა ზემოთ მოცემული ცხრილი საკითხს ვერ წყვეტს, მას ეს კითხვები წყვეტს, დაახლოებით ამ თანმიმდევრობით:

1. რას ელის პროგრამა? თუ სხვის აპლიკაციას აყენებ, გამოიყენე ბაზა, რომელსაც მისი დოკუმენტაცია ასახელებს. WordPress-ის გაშვება MySQL-ის გარდა სხვა რამეზე, ან SQL Server-ის აპლიკაციისა PostgreSQL-ზე, თავისთავად ცალკე პროექტია.
2. რა იცის შენმა გუნდმა? გუნდი, რომელიც T-SQL-სა და SSMS-ს თავისუფლად ფლობს, SQL Server-ს უკეთ ააშენებს და მართავს, ვიდრე PostgreSQL-ს, რომელიც გასულ კვირას ისწავლა, და პირიქით. ბაზის კარგად მართვა - backup-ები, აღდგენები, ნელი query-ები, განახლებები - მის ფუნქციების სიაზე მნიშვნელოვანია.
3. რას მიიჩნევს შენი framework პირველი კლასის არჩევანად? Django და Rails PostgreSQL-ისკენ იხრება; Laravel MySQL-თან და PostgreSQL-თან თანაბრად კარგად მუშაობს; EF Core შესანიშნავია SQL Server-თან და PostgreSQL-თან.
4. რამდენად დიდი გახდება? თუ 10 GB-ზე მეტ მონაცემს წინასწარ ხედავ, Express გრძელვადიან სახლად არასწორია, თუ მოგვიანებით ლიცენზიის საფასურის გადახდისთვის მზად არ ხარ. ღია კოდის ძრავებს ასეთი ჭერი არ აქვთ.
5. რამდენად რელაციურია მონაცემები? მაღალი რელაციურობის მონაცემები SQL ძრავებს ემხრობა; დამოუკიდებელი დოკუმენტები, რომლებიც მთლიანად იკითხება - MongoDB-ს.

რამაც არ უნდა გადაწყვიტოს: benchmark-ების დიაგრამები, ბაზა, რომელსაც დიდი კომპანია იყენებს პრობლემისთვის, რომელიც შენ არ გაქვს, ან სქემის დაპროექტების თავიდან არიდების სურვილი. ამ ბაზებიდან თითოეული პატარა აპლიკაციის დატვირთვას ზომიერ აპარატურაზე უმკლავდება, და თითოეული აჯილდოებს შეგნებულად დაპროექტებულ სქემას.

მოგვიანებით გადასვლა შესაძლებელია, მაგრამ იშვიათად იაფია. SQL ძრავებს შორის გადასვლა ნიშნავს ტიპების კონვერტაციას, ძრავისთვის სპეციფიკური ფუნქციების გამომყენებელი query-ების გადაწერას და ყველაფრის თავიდან ტესტირებას; MongoDB-სა და რელაციურ ბაზას შორის გადასვლა მონაცემთა მოდელის ხელახლა დაპროექტებას ნიშნავს. ერთხელ კარგად არჩევა ერთი შუადღის ფიქრად ღირს.

მათი გაშვება RE:NODE-ზე#

RE:NODE თითოეულ მათგანს ცალკე სერვერად ყიდის: PostgreSQL, MongoDB, MySQL 8.4 LTS, Microsoft SQL Server 2022 Express Linux-ზე და Valkey. თითოეულს უერთდები გეგმაზე ნაჩვენები ჰოსტითა და პორტით, სერვერზე გენერირებული მონაცემებით, და ბაზის გეგმებზე proxy slot არ არის. რამდენიმე დეტალი:

• MySQL მოდის root პაროლით, აპლიკაციის ბაზითა და აპლიკაციის მომხმარებლით, ყველა გენერირებულია.
• SQL Server Express გამოცემაა, sa პაროლით და შენთვის შექმნილი ბაზით, რომელიც sa-ს ნაგულისხმევად არის დაყენებული; SSMS უერთდება სერვერის სახელით host,port, მძიმით, და ყოველი ბაზა გამოცემით 10 GB-ით არის შეზღუდული.
• Valkey პაროლით არის დაცული და დისკზე ინახავს როგორც AOF-ით, ისე snapshot-ებით.

Backup slot-ები ხაზის მიხედვით განსხვავდება: ორიდან ექვსამდე PostgreSQL-სა და MongoDB-ზე, ერთიდან ოთხამდე SQL Server-სა და MySQL-ზე, და ნული ან ერთი Valkey-ზე, სადაც მონაცემები ჩვეულებრივ cache-ია, რომლის ხელახლა აგებაც შეგიძლია. ფასები იწყება დაახლოებით $2-დან თვეში ყველაზე პატარა Valkey გეგმისთვის და $4-დან $7-მდე რელაციური და დოკუმენტური ბაზებისთვის; ბაზების ჰოსტინგის გვერდზე მიმდინარე ციფრებია. რომელიც არ უნდა აირჩიო, საკუთარი ლოგიკური backup-ებიც აიღე - ბაზების backup-ები და აღდგენები ხსნის, რატომ არ უნდა იყოს ჰოსტის ასლი არასოდეს ერთადერთი.

FAQ#

PostgreSQL MySQL-ზე უკეთესია?

ახალი აპლიკაციისთვის თავისუფალი არჩევანით PostgreSQL ჩვეულებრივ უკეთესი ნაგულისხმევია: უფრო მკაცრი, უფრო მდიდარი ფუნქციებით და ტრანზაქციული სქემის ცვლილებებით. MySQL უკეთესი არჩევანია, როცა შენი პროგრამა მისთვის არის დაწერილი, რაც PHP სამყაროს უმეტეს ნაწილს მოიცავს. ორივე მომწიფებული და საკმარისად სწრაფია თითქმის ნებისმიერი პატარა ან საშუალო აპლიკაციისთვის.

საკმარისად კარგია SQL Server Express production-ისთვის?

დიახ, თავისი ლიმიტების ფარგლებში: 10 GB მონაცემები თითო ბაზაზე, ოთხი ბირთვი და დაახლოებით 1.4 GB buffer pool მეხსიერება. ბევრი ბიზნეს-აპლიკაცია მის ფარგლებში წლობით კომფორტულად ცხოვრობს. ზრდა პატიოსნად დაგეგმე, რადგან Express-ის შემდეგი ნაბიჯი ფასიანი ლიცენზიაა.

გამოვიყენო MongoDB, რომ სქემის დაპროექტებას ავარიდო თავი?

არა. სქემა მაინც არსებობს; ის უბრალოდ შენს აპლიკაციის კოდში გადადის, სადაც მისი აღსრულება და შეცვლა უფრო რთულია. აირჩიე MongoDB, როცა შენი მონაცემები მართლა დოკუმენტის ფორმისაა. თუ მხოლოდ რამდენიმე მოქნილი ველი გჭირდება, jsonb სვეტი PostgreSQL-ში ამას გაძლევს join-ებისა და ტრანზაქციების დათმობის გარეშე.

შეიძლება Valkey ჩემი ერთადერთი ბაზა იყოს?

თავისთავად cache-ისთვის, რიგისთვის ან leaderboard-ისთვის - დიახ. აპლიკაციის ძირითადი მონაცემებისთვის - არა: ის მეხსიერებით არის შეზღუდული, არ აქვს query-ის ენა ან join-ები და ისეა დაპროექტებული, რომ მონაცემების ხელახლა აგება შეგეძლოს. დააწყვილე ის რელაციურ ბაზასთან, რომელიც ავტორიტეტულ ასლს ინახავს.

შემიძლია მოგვიანებით ბაზის შეცვლა?

დიახ, მაგრამ ეს პროექტია და არა პარამეტრი. მონაცემთა ტიპები, query-ები, მიგრაციები და ტესტები ყველა იცვლება, და ძრავისთვის სპეციფიკური ფუნქციები უნდა ჩანაცვლდეს. ORM-ის გამოყენება სამუშაოს ამცირებს, მაგრამ არასოდეს აქრობს. დასაწყისშივე შეგნებულად არჩევა უფრო იაფია.

პატარა აპლიკაციას ორი ბაზა სჭირდება?

თავიდან ჩვეულებრივ არა. ერთი რელაციური ბაზა პატარა აპლიკაციის სესიებს, job-ებსა და cache-ს სრულიად კარგად უმკლავდება. Valkey დაამატე, როცა გაზომვადი პრობლემა გაჩნდება - ნელი განმეორებადი query-ები, დატვირთული job-ების რიგი, რამდენიმე პროცესს შორის გაზიარებული სესიები - და არა წინასწარ.