SQL Server (και άλλες databases)

Απ: Eventually consistent ... ?

Panagiotis Kefalidis — Fri, 05 Aug 2011 07:44:34 GMT

Άμα αυτά είναι τα νούμερα, πάω πάσο.. Αλλά ούτε πιστεύω ότι χρειάζεται ένα ακόμα "απλό μηχάνημα" που κοστίζει λιγότερα απο το κόστος που λες, ούτε το πόσο μπορεί να κοστίζει να συντηρείτε μετά αυτό.. Και 30 μέρες για να αλλάξει τα table names στα search queries; Πολλές μου φαίνονται πάλι. Anyway, άλλο ένα πράγμα να θυμάμε για το μέλλον

Άγγελε, όντως μπορεί να έιναι πιο εύκολο να το χωνέψει, έχεις δίκιο.

Απ: Eventually consistent ... ?

Antonios Chatzipavlis — Fri, 05 Aug 2011 07:23:04 GMT

anjelinio:
Ευχαριστώ παίδες για τις απόψεις, όπως πάντα, τίποτα δεν είναι η απόλυτη μια λύση κι απλώς ζυγίζεις ανάλογα τις περιστάσεις τις διαθέσιμες επιλογές. Κι εδώ πλέον έχουμε 2-3 και πολύ ενδιαφέρουσες :)

Πάνο, η αλήθεια είναι ότι ένα ακόμα SQL μηχάνημα πουλιέται πιο εύκολα σαν ιδέα σε ένα συντηρητικό περιβάλλον. Και είναι η πιο εύκολη λύση, το replication δεν τρομάζει ένα DBA.

.. βασικά όμως με τρώει ο κ***ς μου να δοκιμάσω το service broker πρώτα. Θέλω να μπορώ να 'push' notifications έξω.

Δεν θα κερδίσεις ιδιαίτερα με τον service broker. Αν και είμαι φανατικός οπαδός του θα την τρως και πάλι σε locks. To τηλέφωνο μου το ξέρεις πάρε με να μιλήσουμε και να σου εξηγήσω περισσότερα.

Απ: Eventually consistent ... ?

Antonios Chatzipavlis — Fri, 05 Aug 2011 07:18:08 GMT

Στο χωριό μου λένε ότι το φθηνο κρέας το τρώνε οι σκύλοι. Αλλά απο οποία πλευρά και να το δεις πάλι φθηνότερη είναι η λύση που λέω, και αυτο το γράφω με τα εξής κριτήρια
1.O Άγγελος θα πρέπει να δαπανήσει χρόνο για να κάνει την έρευνα για να δει τι θέλει. Αυτο σημαίνει τουλάχιστον 20 ανθρωποημερες εργασίας άρα χονδρικα υπολόγισε 5000€ για αυτές τις ημέρες.
2. Αφού βρει το τι πρέπει να κάνει θα πρέπει να το υλοποιήσει. Αυτό χονδρικα θα θέλει άλλες 30 ημέρες μαζί με 10 ημέρες για τεστ της λύσης. Χονδρικα το κόστος για αυτές είναι 15000€.
Συνυπλογιζοντας στα παραπάνω ότι για αυτές τις ημέρες η παραγωγικότητα όσων χρησιμοποιούν την λύση θα είναι χαμηλή πράγμα που σημαίνει χάσιμο σε χρήμα που αν μπορώ σωστά να κρίνω γνωρίζοντας που είναι ο Άγγελος αυτή την στιγμή μιλάμε για ένα πόσο τουλάχιστον 50000€.
Mε αυτά τα δεδομένα ΕΣΥ τι πιστεύει τώρα; Και μην μου πεις ότι είμαι υπερβολικός και ότι εκει που είσαι τώρα δεν τα σκέφτονται έτσι γιατί σε αυτη τ.ην περίπτωση θα θεώρησω ότι και εκει απο project management και εκτίμηση κόστους είναι ελλαδισταν.

Απ: Eventually consistent ... ?

anjelinio — Fri, 05 Aug 2011 06:59:52 GMT

Ευχαριστώ παίδες για τις απόψεις, όπως πάντα, τίποτα δεν είναι η απόλυτη μια λύση κι απλώς ζυγίζεις ανάλογα τις περιστάσεις τις διαθέσιμες επιλογές. Κι εδώ πλέον έχουμε 2-3 και πολύ ενδιαφέρουσες :)

Πάνο, η αλήθεια είναι ότι ένα ακόμα SQL μηχάνημα πουλιέται πιο εύκολα σαν ιδέα σε ένα συντηρητικό περιβάλλον. Και είναι η πιο εύκολη λύση, το replication δεν τρομάζει ένα DBA.

.. βασικά όμως με τρώει ο κ***ς μου να δοκιμάσω το service broker πρώτα. Θέλω να μπορώ να 'push' notifications έξω.

Απ: Eventually consistent ... ?

Panagiotis Kefalidis — Fri, 05 Aug 2011 04:55:16 GMT

Εσύ βλέπεις το OpEx εγώ βλέπω το CapEx.. Θεωρώ ότι σωστό Implementation είναι φθηνό. Το να ξοδέψουν κάτι χιλιάρικα για ένα Equally δυνατό μηχάνημα μόνο για το Search (με βάση αυτά που λέει ο Άγγελος, ότι το χτυπάνε τόσο συχνά και περισσότερο απο ότι τα CRUD) δεν νομίζω ότι είναι πιο φθηνό απο τις αλλαγές στον κώδικα.. Απο την άλλη αμα δεν έχουμε πλήρη εικόνα, μπορεί να λέμε και σαχλαμαρές έτσι;

Απ: Eventually consistent ... ?

Antonios Chatzipavlis — Fri, 05 Aug 2011 04:14:01 GMT

Είσαι σίγουρος ότι αυτο που προτεινες εινια φθηνό; Γιατί αν τα βάλεις κάτω δεν είναι φθηνό. Το SQL server federation με partitioned tables έχει μεγάλο κόστος σε αλλαγές που θα πρέπει να κάνει στον κώδικα ή στην βάση. Ενώ με αυτο που λέω έχει δυο connections strings ένα σε αυτη που γράφει και ένα σε αυτη που διαβάζει και αλλάζει μόνο τα σημεία που κάνει read

Απ: Eventually consistent ... ?

Panagiotis Kefalidis — Fri, 05 Aug 2011 03:47:02 GMT

Εγώ πάντως πρότεινα το φθηνό σενάριο.. ακού εκεί να στήσεις ολόκληρο άλλο SQL Server.. λεφτά *δεν* υπάρχουν κύριε Χατζηπαυλή.. χεχε.

Απ: Eventually consistent ... ?

Antonios Chatzipavlis — Fri, 05 Aug 2011 03:23:51 GMT

Άγγελε καλησπέρα. Η ιδανική λύση, και δοκιμασμένη ειδικά όταν δεν έχεις χρόνο να κανείς σωστό performance running, είναι το transactional replication. Σε αυτή την περίπτωση ειδικά αν είσαι σε εσωτερικό δίκτυο 1gb το latency που θα έχεις θα είναι τις τάξεως των 10-20 ms. Για να επωφεληθείς από αυτο θα πρέπει την replica να την έχεις σε ξεχωριστή φυσική μηχανή ή αν η κυρία μηχανή σου είναι βαρβατη σε άλλο instance. Η λύση αυτη δουλεύει σε πελάτη μου εδω και 8 χρόνια και πάνω σε μια βάση πάνω απο 2ΤΒ με trillions of rows. Βέβαια πάντα υπάρχει και η δυνατότητα να βυθιστεις μέσα στην δομή της και με τα αντίστοιχα εργαλεία που έχει ο SQL να βρεις την αιτία του κακού που δεν είναι κακο να γίνει κάποια στιγμή.

Απ: Eventually consistent ... ?

Panagiotis Kefalidis — Fri, 05 Aug 2011 03:05:44 GMT

Θα μπορούσαν να παίζουν και τα δύο σαν σενάρια,

Βελτιώσεις στην βάση πχ. Profiling, να δεις execution plans κλπ, και να καταλήξεις εάν όντως είναι optimal ή όχι. Μπορεί να καταλήξεις ότι ο SQL Server δουλεύει στο "όριο" με τα resources που έχει.
Εάν δεν σε νοιάζει το πότε θα υπάρχει consistency μεταξύ search και "real" data, τότε η λύση με τα search tables είναι επίσης καλή. Τράπεζα εδώ στο Βέλγιο το έχει κάνει και δουλεύει μια χαρά. Και μάλιστα το πήγανε κι ένα βήμα παραπέρα κι έχουν multiple search servers με shards ανα πελάτη. Ανάλογα με το/ποιον ψάχνει, χτυπάει κι αντίστοιχο server. Βέβαια η λύση αυτή και πάλι δεν έχει νόημα εάν ο SQL Sever δουλεύει στο όριο απο άποψη resources. Ναι μεν θα είναι πιο γρήγορο, άλλα όχι ιδιαίτερα.

Eventually consistent ... ?

anjelinio — Fri, 05 Aug 2011 01:52:23 GMT

Το σενάριο:

Έχω κάποια tables, με μερικά εκατομμύρια rows το καθένα. Αυτά τρώνε updates / inserts συνεχώς, είναι τα "κύρια" entities του συστήματός μας.
Πάνω στα ίδια tables όμως, τρέχουν και ... searches - με την ίδια ή μεγαλύτερη συχνότητα.
Το αποτέλεσμα ... βραδύτητα .... βραδύτητα ανυπόφορη, ειδικά όταν για μια οθόνη μπορεί να χρειαστεί να τρέχουν 3 - 4 queries βασισμένα σε αυτά τα tables

Δεν "έχω" όλες τις λεπτομέρειες ακόμα, μόλις το κληρονόμησα το εξάμβλωμα και δεν έχω βυθιστεί ακόμα για τα καλά μέσα του, τουλάχιστον ξέρω ότι στα σημαντικά πεδία υπάρχουν indexes, οπότε ημι-αυθαίρετα υποθέτω ότι κάποια στιγμή ξεκινάνε τα locks και συμβαίνει ότι συμβαίνει - που μπορεί να σημαίνει orders of magnitude slower, τα 40 millis 4000 !!!

( please advise αν θα μπορούσα να κοιτάξω κάτι στο setup της όλης κατάστασης για να σας διαφωτίσω περισσότερο επί της κατάστασης )

Η πρώτη σκέψη μου όμως, σαν σωστός over-engineer, ήταν να έχω για τα βασικά μου τέτοια entities, τα αντίστοιχα "search-tables", όπου κρατώ μόνο τα searchable πεδία του καθενός απο τα entities μου, και τρέχω τα searches πάνω σε αυτά, αντί για τα κυρίως tables.

Αλλά θέλω και οι αλλαγές που γίνονται στα κυρίως, τελικά να φτάνουν και ... στα search tables. In a throttled manner, ήσυχα κι ωραία ... κι αν έχω 5 λεπτά lag δε με πειράζει.

Και η ερώτηση ...

Λέω βλακείες; Κάτι απλώς πάει στραβά στο πως είναι αυτά τα tables στη βάση μου, ή/και στον κώδικα που τα χρησιμοποιεί;
Παίζει κάνας Service Broker να με "φτιάξει", και να τον χρησιμοποιήσω μετά και για άλλους σκοπούς μιας και μου δίνει event stream προς τα έξω για τα updates μου;

Ε; Τί λέτε κι εσείς;