Czy istnieją jakieś wyraźne zalety korzystania z narzędzia cql zamiast oszczędności lub czy jest to po prostu przypadek, w którym programiści są zbytnio przyzwyczajeni do SQL? Chciałbym przejść z zapytania do cql, jedynym problemem jest to, że nie jestem pewien co zrobić. Czym oni są?Zalety korzystania z funkcji cql w celu oszczędzania
Zapytania
W CQI można wyszukać Cassandrę i uzyskać dane w kilku liniach (z wykorzystaniem sterownika JDBC):
String query = "SELECT * FROM message;";
PreparedStatement statement = con.prepareStatement(query);
Choć w Thrift opartych API jest to nieco bardziej skomplikowane (przykład z Astyanax):
OperationResult<ColumnList<String>> result =
keyspace.prepareQuery(mail/*specify columnfamily structure*/)
.getKey("[email protected]").execute();
ColumnList<String> columns = result.getResult();
Wydajność
na podstawie benchmarks przeprowadzony przez Acunu, Thrift (RPC) jest nieco lepszy od CQL, jeśli chodzi o wydajność zapytań, ale musisz znajdować się w sytuacji, w której wysoka przepustowość jest kluczowa, aby ta przewaga wydajności przyniosła znaczące korzyści.
Niektóre doskonałych artykułów do wyszukiwania to:
EDIT
Powyższe wartości referencyjne są nieaktualne, a paul pod warunkiem newer benchmarks on prepared statements.
Odpowiedź Lyubena jest dobra, ale wierzę, że może być źle poinformowany w kilku punktach. Po pierwsze, powinieneś wiedzieć, że Thrift API nie otrzyma nowych funkcji; jest tam z myślą o kompatybilności wstecznej i nie jest zalecany do nowych projektów. Istnieją już pewne funkcje, których nie można używać za pośrednictwem interfejsu Thrift.
Kolejnym czynnikiem jest to, że przytoczone benchmarki z Acunu są mylące; nie mierzą wydajności CQL za pomocą przygotowanych instrukcji. Zobacz na przykład wykresy na https://issues.apache.org/jira/browse/CASSANDRA-3634 (prawdopodobnie ten sam zestaw danych, na którym oparty jest post Acunu, ponieważ Eric Evans napisał oba). W ostatnim roku nastąpiły również pewne ulepszenia w analizie składniowej CQL i prędkości wykonywania. Nie jest prawdopodobne, że zaobserwujesz jakąkolwiek rzeczywistą różnicę prędkości pomiędzy CQL 3 a Thrift.
Wreszcie, nie sądzę, żebym nawet zgodził się, że oszczędzanie jest bardziej elastyczne. Datamodel CQL 3 pozwala używać tych samych struktur danych, które Thrift robi dla prawie wszystkich zastosowań, które nie są antipatterns; po prostu pozwala ci myśleć o modelu w bardziej zorganizowany sposób. Na przykład Lyuben wspomniał o wierszach o różnej liczbie kolumn. Tabela CQL 3 może nadal wykorzystywać tę możliwość: istnieje różnica między "rzędami silników pamięci" (czyli niskim poziomem pamięci Cassandra i tym, czego używa Thrift bezpośrednio) i "wierszami CQL" (co widać za pośrednictwem interfejsu Thrift). CQL wykonuje tylko dodatkową pracę niezbędną do wizualizacji rzędów silnika pamięci masowej jako tabel strukturalnych.
Jest to trochę trudne do wyjaśnienia w szybkiej odpowiedzi SO, ale zobacz this post dla nieco łagodnego wyjaśnienia.
CQL nadal pozwala mieć zmienne kolumny w podstawowej strukturze danych, po prostu eksponuje je poprzez wzorce. Jak daje ci możliwość posiadania map, zestawów i list. Które pod maską są zaimplementowane jako zmienne nazwy kolumn. CQL3 próbuje wziąć rzeczy, do których ludzie użyli zmiennych kolumn i wyeksportować te koncepcje wyższego poziomu. Poniższy artykuł omawia niektóre z nich: http://www.datastax.com/dev/blog/thrift-to-cql3 – Zanson
@Zanson Czy przeczytałeś moją odpowiedź? Zauważ, że ten artykuł jest linkiem w nim. –
Tak, przeczytałem, połączyłeś artykuł, ale nie wspomniałeś o żadnych punktach, które on tworzy. Wywołałeś "brak zmiennych nazw kolumn" jako wadę CQL, gdy CQL zapewnia funkcjonalność do wykonywania większości rzeczy, których nazwy zmiennych są użyteczne, bez potrzeby ich używania. – Zanson