There are plenty of Android database management systems you can choose from and you will probably pick one based on multiple factors: intuitiveness/ease of use, flexibility, documentation, performance.. However, if exactly the performance is the major factor, this article might have some answers for you.
您可以从许多Android数据库管理系统中进行选择，并且您可能会基于多个因素来选择一个：直观/易于使用，灵活性，文档， 性能 ..但是，如果性能是主要因素，那么本文可能给你一些答案。
测试设置 (TESTING SETUP)
In this research, I have benchmarked the speed of executing the CRUD operations on various datasets for six highly popular Android DBM systems:
在这项研究中，我对六个高度流行的Android DBM系统在各种数据集上执行CRUD操作的速度进行了基准测试：
- SQLite, SQLite，
- Room Persistence Library, v 2.2.5, Room Persistence Library，v 2.2.5，
- DBFlow, v 4.2.8, DBFlow 4.2.8版，
- GreenDao, v 3.2.2, GreenDao，v 3.2.2，
- Realm, v 6.0.2, 领域，v 6.0.2，
- ObjectBox, v 2.5.1. ObjectBox，2.5.1版。
The benchmarks were done under the standardized conditions. Each DBMS was tested:
基准是在标准化条件下完成的。 每个DBMS均经过测试：
- using the same datasets, 使用相同的数据集
- using the same code-base, 使用相同的代码库
- multiple and the same number of times (49 measures per benchmarked operation per dataset size, with the total of three runs for each test class), 多次且次数相同(每种数据集大小的每个基准操作49个度量，每个测试类总共运行3次)，
- on the same device (Google Pixel 2, Android Q) via the same host, 通过同一主机在同一设备(Google Pixel 2，Android Q)上，
- while the device was in the air-plane mode, 当设备处于飞行模式时，
- while there were no other applications running in the background, 尽管没有其他应用程序在后台运行，
- in the sustained performance mode, 在持续表现模式下
- using the Android Test Orchestrator to ensure the minimum shared state between the tests. 使用Android测试协调器来确保测试之间的最小共享状态。
The datasets used for testing contain 10k, 20k, 30k, 40k and 50k cities. At the moment of conducting the research, I have experienced some issues while running the performance tests with the current version of Android Studio (3.6.3); therefore, I used the Android Debug Bridge (adb) for both running the tests and generating the detailed benchmark reports. However, I gave the tests a run with the newly released version of Android Studio (4.0) and everything seemed to be working fine, at least for the base test runs.
用于测试的数据集包含10k，20k，30k，40k和50k城市。 在进行研究时，我在使用最新版本的Android Studio(3.6.3)进行性能测试时遇到了一些问题。 因此，我使用Android调试桥(adb)来运行测试并生成详细的基准测试报告。 但是，我使用新发布的Android Studio版本(4.0)进行了测试，至少在基本测试运行中，一切似乎运行良好。
As mentioned before, the measurements were made using the Jetpack Benchmark library. Even though I am leaving the library as a topic for another blog, I will quickly brief you about some advantages you can benefit from by using it:
如前所述，使用Jetpack Benchmark库进行测量。 即使我将图书馆作为另一个博客的主题，但我仍将向您简要介绍使用图书馆可带来的一些好处：
- it runs each measurement several times, 它会多次运行每个测量，
- in addition to the multiple measurement runs, you can generate the detailed report for your benchmark results containing different statistical parameters related to the measurements, like the minimum, maximum and median time, 除了进行多次测量外，您还可以为基准测试结果生成详细报告，其中包含与测量相关的不同统计参数，例如最短时间，最大时间和中值时间，
- if using with adb, you will get some extra statistical data in the terminal output, like the mean value and the standard deviation, 如果与adb一起使用，您将在终端输出中获得一些额外的统计数据，例如平均值和标准偏差，
- while using with devices which support the sustained performance mode, the library will use a combination of this API and launching its own activity to both prevent thermal throttling and stabilize results. 在与支持持续性能模式的设备一起使用时，该库将结合使用该API并启动其自身的活动，以防止热调节并稳定结果。
In conclusion, there was 147 measurements made per operation (per dataset size), resulting in total of 2940 measurements made per DBMS and 17 640 measurements for the entire research, which should make the results reliable.
总之，每个操作(每个数据集大小)进行147次测量，因此整个DBMS总共进行2940次测量，整个研究总共进行17640次测量，这应该使结果可靠。
At the end, I ended up with plenty of tables following the later pattern.
最后，按照后面的模式，我得到了大量表。
The mean value of all the runs in milliseconds is used for the further comparison. If you want to fully preview the detailed results, check this sheet.
所有运行的平均值(以毫秒为单位)用于进一步比较。 如果要全面预览详细结果，请查看此表 。
个人结果 (INDIVIDUAL RESULTS)
Each DBMS will be presented with its own, individual results first, and the mutual comparison will be done afterwards.
每个DBMS将首先显示其自己的，单独的结果，然后将进行相互比较。
SQLite:
SQLite：
Comparing to the other relational DBM systems, the times for executing the create and update operations are almost identical.
与其他关系DBM系统相比，执行创建和更新操作的时间几乎相同。
Room:
房间：
There is a clear separation between the times necessary to execute each of the CRUD operations. The speed of deleting the rows is blazing fast.
在执行每个CRUD操作所需的时间之间存在明显的分隔。 删除行的速度非常快。
DBFlow:
DBFlow：
Has the slowest reading speed of all relational DBM systems. For 50 000 rows, the times necessary for reading and creating the rows are almost the same.
在所有关系型DBM系统中读取速度最慢。 对于5万行，读取和创建行所需的时间几乎相同。
GreenDao:
绿岛：
The slowest relational DBMS in terms of updating the data, but the fastest in terms of reading the data from the database.
关系DBMS在更新数据方面最慢，但是在从数据库读取数据方面最快。
Realm:
领域：
No, the Read line is not missing here. Moreover, the speed for reading the data is so fast that its representation on the chart is being covered with the Delete line. Contrary, requires the most time to perform the Create operation, compared to all of the benchmarked DBM systems.
不，这里不缺少读取行。 而且，读取数据的速度是如此之快，以致于其在图表上的表示被删除线所覆盖。 相反，与所有基准DBM系统相比，需要最多时间来执行创建操作。
ObjectBox:
ObjectBox：
A quite nice surprise in terms of performance. This was by far the fastest DBMS taking the overall performance into account.
就性能而言，这是一个非常不错的惊喜。 考虑到整体性能，这是迄今为止最快的DBMS。
相互比较 (MUTUAL COMPARISON)
In this section, the individual results will be mutually compared. For each operation a rank will be formed where database management systems will be positioned from the fastest to the slowest. To form the rank, a coefficient is formed by ranking the DBM systems from the fastest to the slowest for the executed operation per dataset size. For instance, the systems were ranked for reading the 10k rows from the database. They were ranked again for reading 20k rows. The procedure was repeated for all dataset sizes. The final ranking for the operation was created by calculating the average of the previously formed ranks. If the average rank values for two or more DBM systems were the same, a tie was called.
在本节中，将相互比较各个结果。 对于每个操作，都将形成一个等级，在该等级中，数据库管理系统将从最快到最慢。 为了形成等级，通过对每个数据集大小的已执行操作从最快到最慢对DBM系统进行排名来形成系数。 例如，对系统进行了排名，以从数据库中读取1万行。 他们再次排名，以读取2万行。 对所有数据集大小重复该过程。 通过计算先前形成的等级的平均值来创建操作的最终等级。 如果两个或多个DBM系统的平均等级值相同，则称为平局。
Rank: ObjectBox, SQLite, DBFlow, GreenDao, Room, Realm.
排名： ObjectBox，SQLite，DBFlow，GreenDao，Room，Realm。
Rank: Realm, ObjectBox, GreenDao, Room, SQLite, DBFlow.
排名：领域，ObjectBox，GreenDao，Room，SQLite，DBFlow。
Rank: ObjectBox, Realm, SQLite, DBFlow, Room, GreenDao.
排名： ObjectBox，Realm，SQLite，DBFlow，Room，GreenDao。
Rank: Realm, Room, ObjectBox, DBFlow/GreenDao (tie), SQLite.
等级：领域，房间，ObjectBox，DBFlow / GreenDao(并列)，SQLite。
At the end, the average rank was calculated, giving the final, general ordering of the tested database management systems (from the fastest to the slowest):
最后，计算了平均等级，给出了测试数据库管理系统的最终一般顺序(从最快到最慢)：
ObjectBox, Realm, Room/SQLite (tie), DBFlow/GreenDao (tie).
ObjectBox，Realm，Room / SQLite ( 并列 ) ，DBFlow / GreenDao ( 并列 )。
结论 (CONCLUSION)
The scope of the research includes benchmarking of the CRUD operations. The benchmark was made using the Jetpack Benchmark library with the total of 17 640 measurements made. Currently, the object-oriented DBM systems show better results for performing the most of the tested operations. However, that does not have to be the case if more complex operations were introduced.
研究范围包括CRUD操作的基准测试。 使用Jetpack Benchmark库进行基准测试，总共进行了17640次测量。 当前，面向对象的DBM系统对于执行大多数已测试的操作显示出更好的结果。 但是，如果引入了更复杂的操作，则不必如此。
Once again, the presented rankings are related to performance only and do not cover various other factors which may determine which DBMS would suit your project the best.
再次，给出的排名仅与性能相关，并未涵盖其他各种因素，这些因素可能决定哪个DBMS最适合您的项目。
You can check the entire benchmark code on my GitHub.
您可以在我的GitHub上检查整个基准代码 。
Hope this was helpful! Let me know what is your DBMS of choice in the comments. :-)
希望这对您有所帮助！ 让我知道您在评论中选择的DBMS是什么。 :-)
2360
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
