Implementing a distributed key-value store on top of implementing Raft in Go

2 Likes

Desi este ok ca si exercitiu, servicii de genul este de preferat sa fie implementate in limbaje non gc(ex: Aici)

Nu chiar. Discord are alt use case. Uite un use case similar care contrazice ideea ta: Why Go was the right choice for CockroachDB

Formele de stocare distribuita (baze de distribuite, blockchain, noduri diverse,etc) nu sunt despre viteza, pentru ca oricum din cauza timpilor de sincronizare over the network sunt mai lente, nu cred ca problema acelui garbage collector (care se manifesta la limita) influenteaza prea mult performanta unui astfel de sistem. Sunt o multime de alte sisteme de baze de date scrise in Go care merg foarte bine. Daca ar fi sa fac o comparatie cu principalul lui concurent (Rust?) cred ca in acest caz mai mult cantareste simplitatea codului decat performanta.

In al doilea rand performanta in ziua de azi se scaleaza orizontal si nu e o buna practica sa mizezi pe niste performante la nivel de hardware, sistem de operare sau limbaj de programare pentru ca acestea sunt finite iniferent de cat de mult ofera la un moment de timp. In schimb trebuie mers pe scalare din algoritm, ai atins o anumita incarcare fizica, scalezi orizontal. De aia la Google folosesc Go la infrastructura, nu ii intereseaza prea mult limita lui fizica pentru ca nu o ating.

3 Likes

Din minima mea intelegere, nu am avut probleme cu limbajele gc, in special java. Nu am atins limita, ci mai mult o serie de factori ce tin de natura umana cum ar fii erori de programare, au produs probleme. Lucruri care sunt comune peste tot.

Java are o gramada de algoritmi de GC pt multe usecase-uri, cum ar fii latenta, sa consume cat mai putin, pauza cat mai mica, heap gigant etc.

Am dat java ca exemplu, ca cu el am lucrat si lucrez.

As mai adauga la lista alt exemplu din acelasi film, dar scris in java(tot limbaj gc): apache lucene/elasticsearch.

Fix in exemplul discord era distribuit si aveau probleme cu gc(pentru ei a insemnat si reducerea de noduri). Da pentru 99% din useri nu va conta, dar cand scrii un bd vrei cea mai buna performanta. Uite un alt exemplu de gc in js How I Made JavaScript BLAZINGLY FAST - YouTube

Mergand pe ideea ca merge si asa ajungem cu sisteme neoptimizate si plangem ca trebuie cel putin un 4090 sa joci ceva

Cand scrii o baza de date conteaza performanta nu simplitatea codului.

Uite bechmarcuri vs meilisearch Benchmarking Performance: Elasticsearch vs Competitors | by Gigasearch Engineering | gigasearch | Medium

Elastic este atat de folosit din cauza ease of use nu performanta

Atata timp cat nu e distributed, nu poti avea replicas, accepta doar un dataset limitat, exact search nu exista, OR query nu exista, boosting results nu exista si merge cu maximum 200 de indecsi, meilisearch se incadreaza cel mult la categoria hobby. Cel mult vreun startup razlet sa o foloseasca. Si daca ma uit pe lista de clienti a lor, imi dau dreptate singur.

Elasticsearch pe de alta parte, mi se pare ca e king. Si cam asta reiese si din benchmarkurile de mai sus. O zic chiar baietii aia in concluzie.

este king pentru feature si distributed (si este normal ca are niste ani in fata), dar pe lucrurile comune sunt niste diferente mari.

also:

am uitat de Prometheus insusi care este, vrem nu-vrem, un time-series database.

Deci Cassandra, Neo4j, Solr, Prometheus, influxdb si multe altele relativ populare sunt scrise in limbaje gc. Oare ce o fi fost in capul lor…

Prima in lista aia este Casandra care in primul articol postat de mine scrie clar ca e lenta comparativ cu scylladb.
De asemenea tot in acel raspuns: are specifically focused on the Java market, and that’s the main reason why they are written in Java, not (necessarily) because Java was the most suitable implementation language for them. care este fix ce am zis eu in comentul original

1 Like

https://medium.com/paypal-tech/unlocking-the-power-of-junodb-paypals-key-value-store-goes-open-source-ee85f935bdc1

Încă un exemplu de aplicație distribuită scrisă în Go, dar folosită în producție.