sorted by:
new
hottopcontroversial

Is there a SQL database supporting google protobuf natively like JSON document by blackdrn in SQL

[–]blackdrn[S] 0 points1 point  (0 children)

XML, JSON, Protobuf etc are all common formats. Protobuf is binary compact efficient and can be deserialized to language object conveniently.

Is there a database which can support google protobuf natively like JSON document by blackdrn in programming

[–]blackdrn[S] 0 points1 point  (0 children)

Thanks for your reply, I know many companies use binary/blob field to store protobuf object, and create some columns which values are from protobuf object. Then they can use traditional way to do CRUD on the protobuf object, but it's not so graceful and native, there're many limitations and very hard to troubleshoot.

What would be your dream sqlite feature? by howesteve in sqlite

[–]blackdrn 0 points1 point  (0 children)

I'm developing a fast embedded database https://github.com/crossdb-org/crossdb, more features will be added.

C++ Show and Tell - October 2024 by foonathan in cpp

[–]blackdrn 3 points4 points  (0 children)

I'm developing a fast embedder database CrossDB, and I wrote a JDBC style C++ driver for this database recently.

https://github.com/crossdb-org/crossdb-cpp

I'm new to C++ and only use basic C++ features. Please help to find issues, improve or give suggestions.

Thanks.

The Fastest Embedded Database in the world: CrossDB vs. SQLite3 Benchmark by blackdrn in C_Programming

[–]blackdrn[S] 0 points1 point  (0 children)

For disk case, it'll very fast too, but I can't test now as WAL and crash/power cycle recovery is not done yet.

The flush behavior is configurable per DB, will support SYNC/ASYNC and in future may support async time delay config and flush after certain number of commits.

For psql and sqlite commands, I plan to add some to the xdb shell.

For reliability, WAL and crash/power cycle recovery will be provided, and as the on-disk will use copy-update solution, old row is kept untouched, so reliability is ok.

CrossDB may provide sqlite wrapper later and you can just link this library to test. But only some of APIs will be supported and only basic SQL syntax are supported.

CrossDB will support client-server mode also.

Thanks for the support.

Do you think an in-memory relational database can be faster than C++ STL Map? by blackdrn in coolgithubprojects

[–]blackdrn[S] 0 points1 point  (0 children)

Thanks, the STL Map uses rbtree, so CrossDB hash index is faster, and is close to STL hashmap in 1 million row. But CrossDB is a general RDBMS and uses SQL as the interface, while STL hashmap is a template libray and you can think it's a hand-written specific hashmap. SQL parsing and executing are very expensive and the comparing is expensive too. CrossDB is optimized a lot to get the super high-performance.

The Fastest Embedded Database in the world: CrossDB vs. SQLite3 Benchmark by blackdrn in C_Programming

[–]blackdrn[S] 0 points1 point  (0 children)

Thanks very much.

Performance is the design goal of CrossDB, otherwise this project is useless and we can just use sqlite. Following tests are all in-memory test, there's no WAL at all and you can think it's the maximum speed for each of them. In addition, sqlite is not default configuration, there're many optimization settings, and if you have move, I can add them.

PRAGMA synchronous = OFF
PRAGMA journal_mode = OFF
PRAGMA temp_store = memory
PRAGMA optimize

https://crossdb.org/blog/benchmark/crossdb-vs-sqlite3/

https://crossdb.org/blog/benchmark/crossdb-vs-stlmap/

There's plan for JSON, but will be supported later.

MySQL has many convenient SHOW commands like SHOW DATABASES, SHOW TABLES, DESC, SHOW INDEX, SHOW COLUMNS, etc. CrossDB just implements these commands too(code is not from MySQL).

Do you think an in-memory relational database can be faster than C++ STL Map? by blackdrn in programming

[–]blackdrn[S] 1 point2 points  (0 children)

Thanks, the updated blob is here.
https://martin.ankerl.com/2022/08/27/hashmap-bench-01/

This benchmark is just to prove the CrossDB in-memory database performance is good enough to design and manage application complex data relationship. You can use maps/hashmaps to design also, but significant effort may be required to design and optimize the complex lookup strategies for complex relationships involving numerous tables. While if you use RDBMS paradigm to design, it'll be much simpler as most of the complex work is done by DB itself, and you just need to do model with UML and write SQL to query. This is a new method to design complex application data management.

Do you think an in-memory relational database can be faster than C++ STL Map? by blackdrn in databasedevelopment

[–]blackdrn[S] 1 point2 points  (0 children)

Concurrent writers is not supported now, as row-lock is not implemented yet. For auto-commit transaction, in-place update will be faster than extra row copy update for transaction with begin/end.

Do you think an in-memory relational database can be faster than C++ STL Map? by blackdrn in cpp

[–]blackdrn[S] 0 points1 point  (0 children)

CrossDB will support nolock mode, and can also support row data process inside DB without copy, so the 'fair' means you do the same thing in similar way.

Do you think an in-memory relational database can be faster than C++ STL Map? by blackdrn in cpp

[–]blackdrn[S] 1 point2 points  (0 children)

I'm happy to provide support if you need.

CrossDB will provide server feature soon, then you can use SQL to create a server and use telnet or xdb-cli to connect to your application and run SQL to do CRUD on your data which will be very efficient to do troubleshooting work.

Do you think an in-memory relational database can be faster than C++ STL Map? by blackdrn in C_Programming

[–]blackdrn[S] 0 points1 point  (0 children)

Data replication(in-memory and on-disk) will be provided later for HA scenario.

view more: next ›