mirror of
https://gitee.com/milvus-io/milvus.git
synced 2025-12-28 22:45:26 +08:00
c6a1c49e02
issue: #32995 To speed up the construction and querying of Bloom filters, we chose a blocked Bloom filter instead of a basic Bloom filter implementation. WARN: This PR is compatible with old version bf impl, but if fall back to old milvus version, it may causes bloom filter deserialize failed. In single Bloom filter test cases with a capacity of 1,000,000 and a false positive rate (FPR) of 0.001, the blocked Bloom filter is 5 times faster than the basic Bloom filter in both querying and construction, at the cost of a 30% increase in memory usage. - Block BF construct time {"time": "54.128131ms"} - Block BF size {"size": 3021578} - Block BF Test cost {"time": "55.407352ms"} - Basic BF construct time {"time": "210.262183ms"} - Basic BF size {"size": 2396308} - Basic BF Test cost {"time": "192.596229ms"} In multi Bloom filter test cases with a capacity of 100,000, an FPR of 0.001, and 100 Bloom filters, we reuse the primary key locations for all Bloom filters to avoid repeated hash computations. As a result, the blocked Bloom filter is also 5 times faster than the basic Bloom filter in querying. - Block BF TestLocation cost {"time": "529.97183ms"} - Basic BF TestLocation cost {"time": "3.197430181s"} --------- Signed-off-by: Wei Liu <wei.liu@zilliz.com>
Integration test
This folder contains the integration test for Milvus components.
How to run integration test locally
Integration test still need some thirdparty components to start:
cd [milvus-folder]/deployments/docker/dev && docker-compose up -d
Run following script to start the full integration test:
cd [milvus-folder]
make milvus # milvus needs to be compiled to make cpp build ready
./scripts/run_intergration_test.sh
If you want to run single test case, you could execute command like this example
# mq, etcd, minio ready before
cd [milvus-folder]
source scripts/setenv.sh
cd tests/integration/[testcase-folder]/
go test -run "$testCaseName^" -testify.m "$subTestifyCaseName^" -race -v
Recommended coding style for add new cases
Using suite
MiniClusterandMiniClusterSuite` provides lots of comment preset tool function to execute intergration test.
It is recommend to add a new test with testify/suite
import (
// ...
"github.com/milvus-io/milvus/tests/integration"
)
type NewSuite struct {
integration.MiniClusterSuite
}
// Setups and teardowns, optional if no custom logic needed
// example to suite setup & teardown, same logic applies to test setup&teardown
func (s *NewSuite) SetupSuite() {
s.MiniClusterSuite.SetupSuite()
// customized setup
}
func (s *NewSuite) TearDownSuite() {
s.MiniClusterSuite.TearDownSuite()
// customized teardown
}
New folder for each new scenario
It's a known issue that integration test cases run in same process might affect due to some singleton component not fully cleaned.
As a temp solution, test cases are separated into different packages to run independently.