Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

Commit

Permalink
Merge pull request #4 from cmu-db/yenjuw
Browse files Browse the repository at this point in the history
add design rationale and tradeoff to proposal
  • Loading branch information
yenjuw authored Jan 31, 2024
2 parents ad9108b + 0874193 commit 7d85373
Showing 1 changed file with 17 additions and 6 deletions.
23 changes: 17 additions & 6 deletions doc/design_doc.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,11 +11,23 @@
>Explain the input and output of the component, describe interactions and breakdown the smaller components if any. Include diagrams if appropriate.
## Design Rationale
>Explain the goals of this design and how the design achieves these goals. Present alternatives considered and document why they are not chosen.
* Correctness:
* The catalog service ensures data consistency and correctness by adhering to the Iceberg Catalog REST interface.
* Data durability mechanisms will be implemented to prevent data loss during restarts.
* Performance:
* Optimized data retrieval and storage strategies to minimize latency in metadata access.
* Efficient indexing mechanisms to speed up metadata search operations.
* Caching strategies to reduce redundant metadata queries and enhance overall performance.
* Engineering Complexity / Maintainability:
* The microservices architecture simplifies maintenance by encapsulating each building block.
* Code modularity and clear interfaces facilitate easier updates and improvements.
* Testing:
* Comprehensive testing plans cover correctness through unit tests and performance through long-running regression tests. Unit tests focus on individual components of the catalog service, while regression tests evaluate system-wide performance and stability.
* Other Implementations:
* Considered alternative implementations, including a monolithic catalog structure and alternative REST specifications.
* Chose the Iceberg Catalog REST interface due to its industry adoption, standardization, and compatibility with various systems.

## Testing Plan
>How should the component be tested?
To ensure the quality and the performance of the catalog implemented, a comprehensive testing strategy is a must. Our testing strategy will include both functional and non-functional aspects of our catalog service.

* Functional testing
Expand All @@ -26,10 +38,9 @@ To ensure the quality and the performance of the catalog implemented, a comprehe
* Performance evaluation: We will set up a performance baseline to compare the performance of our implementation. We can measure different metrics, for example, response time, throughput, etc.
* Scalability test: We will try to test our implementation under increased load and ensure the correctness and efficiency at the same time.



## Trade-offs and Potential Problems
>Write down any conscious trade-off you made that can be problematic in the future, or any problems discovered during the design process that remain unaddressed (technical debts).
* Balancing between metadata retrieval speed and storage efficiency.
* Striking a balance between query performance and resource utilization.

## Glossary (Optional)
>If you are introducing new concepts or giving unintuitive names to components, write them down here.

0 comments on commit 7d85373

Please sign in to comment.