| Q: | Did you implement GOODS yourself ? How many people worked on it now ? |
|---|---|
| A: | GOODS was designed and implemented by myself. If somebody made some modification or add some new features to GOODS and inform me about it, I usually include this changes in next GOODS release leaving reference to the author. Unfortunately, I am not able to do everything myself (prepare good documentation, create some CASE system for GOODS, implement various import/export utilities to transfer data form other data sources...) I will be glad if somebody will help me with future development and support of GOODS. |
| Q: | Can you perform comparison of GOODS with other commercial OODBMSes ? Do you have some benchmark results for GOODS ? |
| A: | GOODS is distributed OODBMS and its performance is greatly depends on application and network throughput. I didn't try to adopt some standard benchmarks (like OO7 for example) for GOODS because I do not like tests (say me which result you want to get and I will say you which test you should use). If you are worry about performance of your application, it is better to create some prototype implementation and measure it performance. Estimation of application performance and bottlenecks will be much more accurate in this case comparing with results you can get runing some popular DBMS tests. It is not so difficult to prepare interface to this prototype implementation for different OODBMS and compare their performance. If you want I can help you with development such prototype implementation of application for GOODS. |
| Q: | Is Goods being used in any real-world application? Do you have some "success story" list ? Which companies are using GOODS ? |
| A: | As far as I know some software companies are using GOODS, for example Distributed Software Engineering GmbH. I do not have information about "success stories" yet. I will be glad to receive mails with information about projects where GOODS was used. |
| Q: | How well does it scale? Did you test it with 1000 (100000, 1000000, ...) active clients. |
| A: | Topology of GOODS database consists of few storage servers and multiple clients. The number of servers should not be very high (> 10) otherwise high synchronization overhead will cause performance degradation and probability of making database unavailable as a result of crash or communication failure of one of the servers becomes high. From the other side, number of clients can be very large. It is limited only by resources of the system and network throughput. GOODS database server is able to perform a lot of work in parallel, so GOODS can take advantages of SMP architecture and perform concurrent execution of client's requests. Sorry, I had not enough equipment to perform load tests with large number of clients. Once again my advice is to create prototype implementation and run it on equipment you have to perform estimation of performance and find bottlenecks. |
| Q: | How reliable is it? |
| A: | I hope you understand that I am not able to perform exhausted testing myself (also test is a program which helps to find bugs but it can not prove reliability of the program). So program can be called reliable only after some time of it's intensive usage. That is one of the reasons of freeware status of GOODS - I just hope that other developers will help me to make GOODS more reliable. |
| Q: | Are there any additional documentation for GOODS ? |
| A: | All available documentation about GOODS in english is now included in GOODS package. Most of information is placed in readme.htm file. There is separate description of GOODS Java API, client-server communication protocol and JSQL. Also text of my PhD. dissertation about GOODS in russian is available from my homepage. I will going to extend GOODS documentation in near future, but as far as english is not my native language, I will be glad if somebody help me with improving quality of documentation. |