需要提示来优化大管道上的 sybase 访问
我需要从海外访问sybase数据库（12.5）。高延迟肯定是一个问题。
我已经优化了连接参数以更好地利用网络并实现了 20 倍的性能提升，但仍然不够：1 分钟获取 3Mb 的数据。
我们的应用程序还需要增加 10 倍或 20 倍。
技术数据：
- 数据通过使用 TDS 协议的单个 TCP 连接流动
- 客户端应用程序是带有宏的 Excel 工作表，使用默认的 Sybase 驱动程序
- 企业环境使得很难在 10 多年的架构中推动重大变化，因此解决方案需要是干扰最小的。但由于该项目的重要性，一些改变可能会被讨价还价。
有人能给我指点吗？
我已经想到：
- 将 SQL 请求拆分为多个到数据库的并发连接。问题是数据一致性：如果同时修改记录怎么办，因为请求不会完全同时执行？是否存在现有机制可以将请求分散到不同连接上的多个调用上？
- 在海外使用某种数据库“缓存”或“本地复制”，但我不知道有什么可能。
谢谢。
I have the need to access a sybase database (12.5) from oversea. The high latency is definitely a problem.
I already optimized the connection parameters to make better use of the network and achieved a 20x performance increase, but it's still not enough : 1 minute to get 3Mb of data.
We need another 10x or 20x increase for our application.
Technical data :
- the data are flowing through a single TCP connection using the TDS protocol
- the client app is an excel sheet with macros, using the default Sybase driver
- the corporate environment makes it difficult to push big changes in the 10+ years architecture, so solutions need to be the least intrusive. But some changes may be bargained due to the importance of this project.
Can anyone give me pointers ?
I already thought of :
- splitting SQL requests over several concurrent connections to the database. The problem is data consistency : what if records are modified at the same time since requests will not be exactly executed at the same time ? Is there an existing mechanism to spread a request over several calls on different connections ?
- using some kind of database "cache" or "local replication" oversea, but I don't know what is possible.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尝试安装本地数据库（ASE 或 ASA）并将此数据库与 Sybase Mobilink（如果您需要较小的复制延迟并且您有很多钱，则使用 Sybase Replication Server）同步该数据库。
Try to install local database (ASE or ASA) and synchronize this databases with Sybase Mobilink (or Sybase Replication Server if you need small replication latency and you have a lot of money).
（我知道我回答了我自己的问题）
最终，我们决定设计自己的数据库远程访问协议。它并不复杂，因为我们只使用 SQL 的基本子集（SELECT 和 UPDATE），并且协议无论如何都不必理解 SQL。
通过使用我们自己的协议，我们将能够使用压缩，使客户端能够同时使用多个 TCP 链接，最大限度地提高网络利用率，并为我们的应用程序添加一些特定的功能缓存。
客户端将是我们的应用程序，服务器将是真实数据库的“代理”，位于它旁边（就像@Tim 在评论中建议的那样）。
它不是唯一的解决方案，但我们认为它在巨大的复制成本、开发复杂性和预期收益之间取得了良好的平衡。
(I know I answer to my own question)
Eventually, we settled to designing our own database remote access protocol. It's not complicated since we are only using a basic subset of SQL (SELECT and UPDATE), and the protocol doesn't have to understand SQL anyway.
By using our own protocol, we'll be able to use compression, make the client able to use several TCP links at the same time, maximize network utilisation and add some functionnal caching secific to our application.
The client will be our app and the server will be a "proxy" to the real database, sitting next to it (like @Tim suggested in the comments).
It's not the only solution, but we feel that it's a good balance between enormous replication price, development complexity and expected benefits.